Is anybody using FileTree repositories? If so, I'd like to know the pros and cons of using it. I want to use to version everything with git, but I don't know how it keeps git (it is, FileTree files) in sync with MC versions. Regards! Esteban A. Maringolo
I wish. I think that what is done with the VM (still need to catch up on that "new way") is a great way to go. Are there resources about that? Regards, Phil On Fri, Sep 13, 2013 at 4:25 AM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
Is anybody using FileTree repositories?
If so, I'd like to know the pros and cons of using it.
I want to use to version everything with git, but I don't know how it keeps git (it is, FileTree files) in sync with MC versions.
Regards!
Esteban A. Maringolo
Le 13/09/2013 04:25, Esteban A. Maringolo a écrit :
Is anybody using FileTree repositories?
Which repositories? Dale's github?
If so, I'd like to know the pros and cons of using it.
More complex to use than Smalltalkhub/Squeaksource because it is not yet integrated in the default image. Some features may not work, but average MC work under Pharo2.0 works fine with all features of Filetree (including gitfiletree). Easier to use than Smalltalkhub/Squeaksource for authentification.
I want to use to version everything with git, but I don't know how it keeps git (it is, FileTree files) in sync with MC versions.
A filetree repository appears as a MC repository in the same way as another type of MC repository. Filetree will require that you do all your version management in the git repo by hand (i.e. save a version of your package in a filetree repo, then switch to a console to commit it. If you forget to commit and save a new version of a package on the filetree repo, you overwrite the previous version and git will not record it. Filetree by itself will only show you the state of the HEAD of your git repository). If you use gitfiletree (it sits over Filetree), then git commit will be done for you when saving your package, and the repository browser will show you all the history of the repository, exactly as if it was a Smalltalkhub or Squeaksource repository. What will remain to do on the command line are the git push and whatever management you do on the repository (merging, branching, even if you can also merge via MC instead). In short, gitfiletree calls git for you and parse the results :) I'm still wondering about adding more git commands inside the MC GUI to do more from inside Pharo (like automagically pushing), but I don't want to enforce a specific way of organising the git repository... and I'm just trying to get gitfiletree to pass its tests in the pharo3.0 branch of Filetree at the moment. Does this answer your questions? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Goubier, You do answer my questions. I'm certainly looking for something like gitfiletree then. One last question I have is, does the gitfiletree:// repository type come bundled with the FileTree package? Or do I need to download and install it separately? Regarding adding more git commands inside the MC GUI I'd like to have them separated. Unless I can load previous versions of my MC package and that causes the git to checkout the files from a previous commit. I don't know how the branching is managed or if it's simply ignored. Regards, Esteban A. Maringolo 2013/9/13 Goubier Thierry <thierry.goubier@cea.fr>
Le 13/09/2013 04:25, Esteban A. Maringolo a écrit :
Is anybody using FileTree repositories?
Which repositories? Dale's github?
If so, I'd like to know the pros and cons of using it.
More complex to use than Smalltalkhub/Squeaksource because it is not yet integrated in the default image. Some features may not work, but average MC work under Pharo2.0 works fine with all features of Filetree (including gitfiletree).
Easier to use than Smalltalkhub/Squeaksource for authentification.
I want to use to version everything with git, but I don't know how it
keeps git (it is, FileTree files) in sync with MC versions.
A filetree repository appears as a MC repository in the same way as another type of MC repository.
Filetree will require that you do all your version management in the git repo by hand (i.e. save a version of your package in a filetree repo, then switch to a console to commit it. If you forget to commit and save a new version of a package on the filetree repo, you overwrite the previous version and git will not record it. Filetree by itself will only show you the state of the HEAD of your git repository).
If you use gitfiletree (it sits over Filetree), then git commit will be done for you when saving your package, and the repository browser will show you all the history of the repository, exactly as if it was a Smalltalkhub or Squeaksource repository. What will remain to do on the command line are the git push and whatever management you do on the repository (merging, branching, even if you can also merge via MC instead). In short, gitfiletree calls git for you and parse the results :)
I'm still wondering about adding more git commands inside the MC GUI to do more from inside Pharo (like automagically pushing), but I don't want to enforce a specific way of organising the git repository... and I'm just trying to get gitfiletree to pass its tests in the pharo3.0 branch of Filetree at the moment.
Does this answer your questions?
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 13/09/2013 16:30, Esteban A. Maringolo a écrit :
Goubier,
You do answer my questions. I'm certainly looking for something like gitfiletree then.
One last question I have is, does the gitfiletree:// repository type come bundled with the FileTree package? Or do I need to download and install it separately?
Yes, I think it is in the default configuration for pharo 2.0.
Regarding adding more git commands inside the MC GUI I'd like to have them separated. Unless I can load previous versions of my MC package and that causes the git to checkout the files from a previous commit.
No, it does a lot better than that. It loads the definitions of a previous version of a package without doing a checkout on the repo, to do with it in MC as you want : load/merge/compare changes. If you know git, it uses 'git archive' to retrieve a specific package version in the commit history. It also bypass most of the stored metadata in the package: methods timestamps are the git commit timestamps, package history is the git commit history of the repo (pruned to remove all commits not related to the package, in the case of a repo containing multiple packages).
I don't know how the branching is managed or if it's simply ignored.
I'm displaying it in the repository inspector, otherwise it's ignored. Thierry
Regards,
Esteban A. Maringolo
2013/9/13 Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>>
Le 13/09/2013 04:25, Esteban A. Maringolo a écrit :
Is anybody using FileTree repositories?
Which repositories? Dale's github?
If so, I'd like to know the pros and cons of using it.
More complex to use than Smalltalkhub/Squeaksource because it is not yet integrated in the default image. Some features may not work, but average MC work under Pharo2.0 works fine with all features of Filetree (including gitfiletree).
Easier to use than Smalltalkhub/Squeaksource for authentification.
I want to use to version everything with git, but I don't know how it keeps git (it is, FileTree files) in sync with MC versions.
A filetree repository appears as a MC repository in the same way as another type of MC repository.
Filetree will require that you do all your version management in the git repo by hand (i.e. save a version of your package in a filetree repo, then switch to a console to commit it. If you forget to commit and save a new version of a package on the filetree repo, you overwrite the previous version and git will not record it. Filetree by itself will only show you the state of the HEAD of your git repository).
If you use gitfiletree (it sits over Filetree), then git commit will be done for you when saving your package, and the repository browser will show you all the history of the repository, exactly as if it was a Smalltalkhub or Squeaksource repository. What will remain to do on the command line are the git push and whatever management you do on the repository (merging, branching, even if you can also merge via MC instead). In short, gitfiletree calls git for you and parse the results :)
I'm still wondering about adding more git commands inside the MC GUI to do more from inside Pharo (like automagically pushing), but I don't want to enforce a specific way of organising the git repository... and I'm just trying to get gitfiletree to pass its tests in the pharo3.0 branch of Filetree at the moment.
Does this answer your questions?
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 09/13/2013 07:53 AM, Goubier Thierry wrote:
It also bypass most of the stored metadata in the package: methods timestamps are the git commit timestamps, package history is the git commit history of the repo (pruned to remove all commits not related to the package, in the case of a repo containing multiple packages).
So does this mean that If I make a bug fix in someone's package and then commit it, I become the author of every method of the package? Or can it tell from the commit that its just that one method that changed and all the other methods are from prior commits? Also, when beginning to use git, if I make the initial commit of the package is all the prior editing and version history lost? Thanks Paul
2013/9/13 Paul DeBruicker <pdebruic@gmail.com>
Also, when beginning to use git, if I make the initial commit of the package is all the prior editing and version history lost?
It happened to me. Maybe there is a way of, in a blank image, load the MC package editions from a regular repo and commit them in the GitFileTree one. It is... to replay every commit in the new repo. Esteban A. Maringolo
Yes, there is a way. If you use a Gofer import script[1] to move a package from say, a squeaksource repository to a git repository with gitfiletree, you will import and commit all the versions one by one inside the git repo, starting with the oldest. You will loose the timestamps, but not the history. Thierry [1] I should give you a link, but a google "Gofer migrate from Squeaksource to Smalltalkhub" should bring you to a few good blog pages with scripts example, something along the lines of Gofer fetch. Gofer push :) ________________________________________ De : Pharo-users [pharo-users-bounces@lists.pharo.org] de la part de Esteban A. Maringolo [emaringolo@gmail.com] Date d'envoi : vendredi 13 septembre 2013 17:52 Ã : Any question about pharo is welcome Objet : Re: [Pharo-users] FileTree Monticello Repository 2013/9/13 Paul DeBruicker <pdebruic@gmail.com>
Also, when beginning to use git, if I make the initial commit of the package is all the prior editing and version history lost?
It happened to me. Maybe there is a way of, in a blank image, load the MC package editions from a regular repo and commit them in the GitFileTree one. It is... to replay every commit in the new repo. Esteban A. Maringolo
When you change a method and save, git will see one file changed (the method) and put it in the commit (there will also be a few changes in the metadata associated with the method and this will be included in the commit, but this won't matter for gitfiletree). Everything else will stay as before, i.e. owned by the original author (if it is done on git). Additionally, the message in the git log will be the one you wrote for the package in MC when saving. When you start to use git, what you should do is move all your package versions onto the new repository, for example with a Gofer script. It will commit all the versions, starting from the first one, and so recreate the history (but without the merges and resetting timestamps and attributing ownership to you); I don't know enough of git to do a perfect history import, but it could be done. Thierry ________________________________________ De : Pharo-users [pharo-users-bounces@lists.pharo.org] de la part de Paul DeBruicker [pdebruic@gmail.com] Date d'envoi : vendredi 13 septembre 2013 17:47 Ã : pharo-users@lists.pharo.org Objet : Re: [Pharo-users] FileTree Monticello Repository On 09/13/2013 07:53 AM, Goubier Thierry wrote:
It also bypass most of the stored metadata in the package: methods timestamps are the git commit timestamps, package history is the git commit history of the repo (pruned to remove all commits not related to the package, in the case of a repo containing multiple packages).
So does this mean that If I make a bug fix in someone's package and then commit it, I become the author of every method of the package? Or can it tell from the commit that its just that one method that changed and all the other methods are from prior commits? Also, when beginning to use git, if I make the initial commit of the package is all the prior editing and version history lost? Thanks Paul
Goubier Thierry wrote:
Le 13/09/2013 04:25, Esteban A. Maringolo a écrit :
Is anybody using FileTree repositories?
Which repositories? Dale's github?
If so, I'd like to know the pros and cons of using it.
More complex to use than Smalltalkhub/Squeaksource because it is not yet integrated in the default image. Some features may not work, but average MC work under Pharo2.0 works fine with all features of Filetree (including gitfiletree).
Easier to use than Smalltalkhub/Squeaksource for authentification.
I want to use to version everything with git, but I don't know how it keeps git (it is, FileTree files) in sync with MC versions.
A filetree repository appears as a MC repository in the same way as another type of MC repository.
Filetree will require that you do all your version management in the git repo by hand (i.e. save a version of your package in a filetree repo, then switch to a console to commit it. If you forget to commit and save a new version of a package on the filetree repo, you overwrite the previous version and git will not record it. Filetree by itself will only show you the state of the HEAD of your git repository).
If you use gitfiletree (it sits over Filetree), then git commit will be done for you when saving your package, and the repository browser will show you all the history of the repository, exactly as if it was a Smalltalkhub or Squeaksource repository. What will remain to do on the command line are the git push and whatever management you do on the repository (merging, branching, even if you can also merge via MC instead). In short, gitfiletree calls git for you and parse the results :)
I'm still wondering about adding more git commands inside the MC GUI to do more from inside Pharo (like automagically pushing), but I don't want to enforce a specific way of organising the git repository... and I'm just trying to get gitfiletree to pass its tests in the pharo3.0 branch of Filetree at the moment.
Does this answer your questions?
Thierry but I don't want to enforce a specific way of organising the git
repository I see this extreme altruism :) around the community, and while it is very admirable, I think sometimes its misplaced :). The flip side is that some people (like me) aren't really familiar with git don't know how we might want git organised, or even what the options are. Unfortunately this stalls my motivation to try it out (sorry, weak, I know - but I admit it, and I think its common (or do I just think that to make myself feel better)). Having a concrete implementation of any additional functionality that might make git more transparent "out of the box" would be beneficial for its uptake. As well, without a concrete example, others who might want to implement something like that have to start more from scratch, whereas your concrete example might be 90% of what someone wants and then its only 10% that they need to customize. The reality of human nature is that its easier to criticize to pick out what you don't like, than to create something new. However the hidden benefit of this criticism is that it engages people in discussion and then you hook them into helping develop what they need. So anyway, my short response is, if "you" would benefit from that added functionality then "just do it". :) cheers -ben P.S. I admire what I read about progress with Filtetree and GitFileTree towards using git. For some segments outside the Pharo community that we want to draw in, this is going to be an important consideration.
Le 13/09/2013 17:04, btc@openinworld.com a écrit :
Goubier Thierry wrote:
Le 13/09/2013 04:25, Esteban A. Maringolo a écrit :
Is anybody using FileTree repositories?
Which repositories? Dale's github?
If so, I'd like to know the pros and cons of using it.
More complex to use than Smalltalkhub/Squeaksource because it is not yet integrated in the default image. Some features may not work, but average MC work under Pharo2.0 works fine with all features of Filetree (including gitfiletree).
Easier to use than Smalltalkhub/Squeaksource for authentification.
I want to use to version everything with git, but I don't know how it keeps git (it is, FileTree files) in sync with MC versions.
A filetree repository appears as a MC repository in the same way as another type of MC repository.
Filetree will require that you do all your version management in the git repo by hand (i.e. save a version of your package in a filetree repo, then switch to a console to commit it. If you forget to commit and save a new version of a package on the filetree repo, you overwrite the previous version and git will not record it. Filetree by itself will only show you the state of the HEAD of your git repository).
If you use gitfiletree (it sits over Filetree), then git commit will be done for you when saving your package, and the repository browser will show you all the history of the repository, exactly as if it was a Smalltalkhub or Squeaksource repository. What will remain to do on the command line are the git push and whatever management you do on the repository (merging, branching, even if you can also merge via MC instead). In short, gitfiletree calls git for you and parse the results :)
I'm still wondering about adding more git commands inside the MC GUI to do more from inside Pharo (like automagically pushing), but I don't want to enforce a specific way of organising the git repository... and I'm just trying to get gitfiletree to pass its tests in the pharo3.0 branch of Filetree at the moment.
Does this answer your questions?
Thierry but I don't want to enforce a specific way of organising the git
repository
I see this extreme altruism :) around the community, and while it is very admirable, I think sometimes its misplaced :). The flip side is that some people (like me) aren't really familiar with git don't know how we might want git organised, or even what the options are. Unfortunately this stalls my motivation to try it out (sorry, weak, I know - but I admit it, and I think its common (or do I just think that to make myself feel better)). Having a concrete implementation of any additional functionality that might make git more transparent "out of the box" would be beneficial for its uptake. As well, without a concrete example, others who might want to implement something like that have to start more from scratch, whereas your concrete example might be 90% of what someone wants and then its only 10% that they need to customize. The reality of human nature is that its easier to criticize to pick out what you don't like, than to create something new. However the hidden benefit of this criticism is that it engages people in discussion and then you hook them into helping develop what they need. So anyway, my short response is, if "you" would benefit from that added functionality then "just do it". :) cheers -ben
P.S. I admire what I read about progress with Filtetree and GitFileTree towards using git. For some segments outside the Pharo community that we want to draw in, this is going to be an important consideration.
Hi Ben, I'm sorry that this doesn't convince you to use git with Pharo :) So far, I very happy with the functionality gitfiletree has; for a common user like me it has been working very nicely for quite some time now :):) It has the features I need: allow the introduction of pharo development in any pre-existing / mixed language repository; allow me to build in 5 sec a new repo for a package; integrate with github; better long history exploration than anything else under Pharo. At the same time, it was a bit of a mock-up, this gitfiletree: just adding some automation to a filetree over git repository, and also add some motivation for someone else to see what can be done and how, so as to eventually reimplement it as a FileSystem / or as a libcgit instead of calling git log and git archive :) It's now a bit of a bench for some future directions of FileTree, such as removing the metadata which is provoking conflicts when merging under git, or as a new replacement of changesets (but EPICEA is going in another interesting direction, so I'm not trying anything there). And don't worry for my altruism not adding functionalities :) I'm the guy who wrote a complete alternative IDE for pharo 2.0, just because I prefer it to Nautilus :O Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Thierry I think that what ben want to say is: - provide a default "but I don't want to enforce a specific way of organising the git repository⦠" Stef PS: I would love to be able to use git for managing Pharo so keep pushing. Now we cannot allocate more resources to this task but last year I request to inria some resources for this task (and it was rejected).
Le 13/09/2013 17:04, btc@openinworld.com a écrit :
Goubier Thierry wrote:
Le 13/09/2013 04:25, Esteban A. Maringolo a écrit :
Is anybody using FileTree repositories?
Which repositories? Dale's github?
If so, I'd like to know the pros and cons of using it.
More complex to use than Smalltalkhub/Squeaksource because it is not yet integrated in the default image. Some features may not work, but average MC work under Pharo2.0 works fine with all features of Filetree (including gitfiletree).
Easier to use than Smalltalkhub/Squeaksource for authentification.
I want to use to version everything with git, but I don't know how it keeps git (it is, FileTree files) in sync with MC versions.
A filetree repository appears as a MC repository in the same way as another type of MC repository.
Filetree will require that you do all your version management in the git repo by hand (i.e. save a version of your package in a filetree repo, then switch to a console to commit it. If you forget to commit and save a new version of a package on the filetree repo, you overwrite the previous version and git will not record it. Filetree by itself will only show you the state of the HEAD of your git repository).
If you use gitfiletree (it sits over Filetree), then git commit will be done for you when saving your package, and the repository browser will show you all the history of the repository, exactly as if it was a Smalltalkhub or Squeaksource repository. What will remain to do on the command line are the git push and whatever management you do on the repository (merging, branching, even if you can also merge via MC instead). In short, gitfiletree calls git for you and parse the results :)
I'm still wondering about adding more git commands inside the MC GUI to do more from inside Pharo (like automagically pushing), but I don't want to enforce a specific way of organising the git repository... and I'm just trying to get gitfiletree to pass its tests in the pharo3.0 branch of Filetree at the moment.
Does this answer your questions?
Thierry but I don't want to enforce a specific way of organising the git
repository
I see this extreme altruism :) around the community, and while it is very admirable, I think sometimes its misplaced :). The flip side is that some people (like me) aren't really familiar with git don't know how we might want git organised, or even what the options are. Unfortunately this stalls my motivation to try it out (sorry, weak, I know - but I admit it, and I think its common (or do I just think that to make myself feel better)). Having a concrete implementation of any additional functionality that might make git more transparent "out of the box" would be beneficial for its uptake. As well, without a concrete example, others who might want to implement something like that have to start more from scratch, whereas your concrete example might be 90% of what someone wants and then its only 10% that they need to customize. The reality of human nature is that its easier to criticize to pick out what you don't like, than to create something new. However the hidden benefit of this criticism is that it engages people in discussion and then you hook them into helping develop what they need. So anyway, my short response is, if "you" would benefit from that added functionality then "just do it". :) cheers -ben
P.S. I admire what I read about progress with Filtetree and GitFileTree towards using git. For some segments outside the Pharo community that we want to draw in, this is going to be an important consideration.
Hi Ben,
I'm sorry that this doesn't convince you to use git with Pharo :)
So far, I very happy with the functionality gitfiletree has; for a common user like me it has been working very nicely for quite some time now :):) It has the features I need: allow the introduction of pharo development in any pre-existing / mixed language repository; allow me to build in 5 sec a new repo for a package; integrate with github; better long history exploration than anything else under Pharo.
At the same time, it was a bit of a mock-up, this gitfiletree: just adding some automation to a filetree over git repository, and also add some motivation for someone else to see what can be done and how, so as to eventually reimplement it as a FileSystem / or as a libcgit instead of calling git log and git archive :)
It's now a bit of a bench for some future directions of FileTree, such as removing the metadata which is provoking conflicts when merging under git, or as a new replacement of changesets (but EPICEA is going in another interesting direction, so I'm not trying anything there).
And don't worry for my altruism not adding functionalities :) I'm the guy who wrote a complete alternative IDE for pharo 2.0, just because I prefer it to Nautilus :O
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Git it is not just a benefit for outsiders, it is for Smalltalkers too. In the company I work for (we use Dolphin), we moved away from its VCS (STS, an ENVY like repo) a few months ago to file based packages (Dolphin supports this format too to be used by "regular" VCS, in a one dir per package, one file per class basis). Now we version everything with git. I'm talking about a huge system (thousands of classes, and LOTS of SLOC). After moving to git we were able to leverage existing tools for continuous integration tools with simple build scripts. We already made two production releases (another one coming at the end of the month), and the branching capabilities is really useful to apply hotfixes to previous releases. We're all happy with its outcome. We're building runtime (deploy) versions, and development images continuously, in less than 5 minutes. I'm no git expert, and no MC "proficient user" either. But I'm trying to replicate what we have in my personal projects. That's why FileTree caught my attention way back when Dale Henrichs started coding it. I still have to get my head around the packaging system of Pharo, I don't understand it, or actually I'm not sure if I do or not, because there is PackageInfo, Monticello, RPackage. Metacello is a different beast I'm getting to know because of its resemblance with ENVY's ConfigurationMaps. So... bottom line, I'll give gitfiletree repos a try, and see how it goes. Regards! Esteban A. Maringolo 2013/9/13 <btc@openinworld.com>
Goubier Thierry wrote:
Le 13/09/2013 04:25, Esteban A. Maringolo a écrit :
Is anybody using FileTree repositories?
Which repositories? Dale's github?
If so, I'd like to know the pros and cons of using it.
More complex to use than Smalltalkhub/Squeaksource because it is not yet integrated in the default image. Some features may not work, but average MC work under Pharo2.0 works fine with all features of Filetree (including gitfiletree).
Easier to use than Smalltalkhub/Squeaksource for authentification.
I want to use to version everything with git, but I don't know how it
keeps git (it is, FileTree files) in sync with MC versions.
A filetree repository appears as a MC repository in the same way as another type of MC repository.
Filetree will require that you do all your version management in the git repo by hand (i.e. save a version of your package in a filetree repo, then switch to a console to commit it. If you forget to commit and save a new version of a package on the filetree repo, you overwrite the previous version and git will not record it. Filetree by itself will only show you the state of the HEAD of your git repository).
If you use gitfiletree (it sits over Filetree), then git commit will be done for you when saving your package, and the repository browser will show you all the history of the repository, exactly as if it was a Smalltalkhub or Squeaksource repository. What will remain to do on the command line are the git push and whatever management you do on the repository (merging, branching, even if you can also merge via MC instead). In short, gitfiletree calls git for you and parse the results :)
I'm still wondering about adding more git commands inside the MC GUI to do more from inside Pharo (like automagically pushing), but I don't want to enforce a specific way of organising the git repository... and I'm just trying to get gitfiletree to pass its tests in the pharo3.0 branch of Filetree at the moment.
Does this answer your questions?
Thierry
but I don't want to enforce a specific way of organising the git
repository
I see this extreme altruism :) around the community, and while it is very admirable, I think sometimes its misplaced :). The flip side is that some people (like me) aren't really familiar with git don't know how we might want git organised, or even what the options are. Unfortunately this stalls my motivation to try it out (sorry, weak, I know - but I admit it, and I think its common (or do I just think that to make myself feel better)). Having a concrete implementation of any additional functionality that might make git more transparent "out of the box" would be beneficial for its uptake. As well, without a concrete example, others who might want to implement something like that have to start more from scratch, whereas your concrete example might be 90% of what someone wants and then its only 10% that they need to customize. The reality of human nature is that its easier to criticize to pick out what you don't like, than to create something new. However the hidden benefit of this criticism is that it engages people in discussion and then you hook them into helping develop what they need. So anyway, my short response is, if "you" would benefit from that added functionality then "just do it". :) cheers -ben
P.S. I admire what I read about progress with Filtetree and GitFileTree towards using git. For some segments outside the Pharo community that we want to draw in, this is going to be an important consideration.
As a I side note: I know Dale uses FileTree repos to publish his projects to GitHub and build it with Travis CI. For many people is okay with using SmalltalkHub to publish their MC Packages, and that's fine and a real progress compared with SqueakSource. But there are no "private repositories" in GitHub nor SmalltalkHub and not everybody does open source software nor have servers on their own premises. I'm already using BitBucket for my non-smalltalk code, and and I already pushed my MC FileTree based packages to it. I like how it looks. Regards! Esteban A. Maringolo 2013/9/13 Esteban A. Maringolo <emaringolo@gmail.com>
Git it is not just a benefit for outsiders, it is for Smalltalkers too.
In the company I work for (we use Dolphin), we moved away from its VCS (STS, an ENVY like repo) a few months ago to file based packages (Dolphin supports this format too to be used by "regular" VCS, in a one dir per package, one file per class basis).
Now we version everything with git. I'm talking about a huge system (thousands of classes, and LOTS of SLOC).
After moving to git we were able to leverage existing tools for continuous integration tools with simple build scripts. We already made two production releases (another one coming at the end of the month), and the branching capabilities is really useful to apply hotfixes to previous releases. We're all happy with its outcome. We're building runtime (deploy) versions, and development images continuously, in less than 5 minutes.
I'm no git expert, and no MC "proficient user" either. But I'm trying to replicate what we have in my personal projects.
That's why FileTree caught my attention way back when Dale Henrichs started coding it.
I still have to get my head around the packaging system of Pharo, I don't understand it, or actually I'm not sure if I do or not, because there is PackageInfo, Monticello, RPackage. Metacello is a different beast I'm getting to know because of its resemblance with ENVY's ConfigurationMaps.
So... bottom line, I'll give gitfiletree repos a try, and see how it goes.
Regards!
Esteban A. Maringolo
2013/9/13 <btc@openinworld.com>
Goubier Thierry wrote:
Le 13/09/2013 04:25, Esteban A. Maringolo a écrit :
Is anybody using FileTree repositories?
Which repositories? Dale's github?
If so, I'd like to know the pros and cons of using it.
More complex to use than Smalltalkhub/Squeaksource because it is not yet integrated in the default image. Some features may not work, but average MC work under Pharo2.0 works fine with all features of Filetree (including gitfiletree).
Easier to use than Smalltalkhub/Squeaksource for authentification.
I want to use to version everything with git, but I don't know how it
keeps git (it is, FileTree files) in sync with MC versions.
A filetree repository appears as a MC repository in the same way as another type of MC repository.
Filetree will require that you do all your version management in the git repo by hand (i.e. save a version of your package in a filetree repo, then switch to a console to commit it. If you forget to commit and save a new version of a package on the filetree repo, you overwrite the previous version and git will not record it. Filetree by itself will only show you the state of the HEAD of your git repository).
If you use gitfiletree (it sits over Filetree), then git commit will be done for you when saving your package, and the repository browser will show you all the history of the repository, exactly as if it was a Smalltalkhub or Squeaksource repository. What will remain to do on the command line are the git push and whatever management you do on the repository (merging, branching, even if you can also merge via MC instead). In short, gitfiletree calls git for you and parse the results :)
I'm still wondering about adding more git commands inside the MC GUI to do more from inside Pharo (like automagically pushing), but I don't want to enforce a specific way of organising the git repository... and I'm just trying to get gitfiletree to pass its tests in the pharo3.0 branch of Filetree at the moment.
Does this answer your questions?
Thierry
but I don't want to enforce a specific way of organising the git
repository
I see this extreme altruism :) around the community, and while it is very admirable, I think sometimes its misplaced :). The flip side is that some people (like me) aren't really familiar with git don't know how we might want git organised, or even what the options are. Unfortunately this stalls my motivation to try it out (sorry, weak, I know - but I admit it, and I think its common (or do I just think that to make myself feel better)). Having a concrete implementation of any additional functionality that might make git more transparent "out of the box" would be beneficial for its uptake. As well, without a concrete example, others who might want to implement something like that have to start more from scratch, whereas your concrete example might be 90% of what someone wants and then its only 10% that they need to customize. The reality of human nature is that its easier to criticize to pick out what you don't like, than to create something new. However the hidden benefit of this criticism is that it engages people in discussion and then you hook them into helping develop what they need. So anyway, my short response is, if "you" would benefit from that added functionality then "just do it". :) cheers -ben
P.S. I admire what I read about progress with Filtetree and GitFileTree towards using git. For some segments outside the Pharo community that we want to draw in, this is going to be an important consideration.
On 09/13/2013 08:50 AM, Esteban A. Maringolo wrote:
But there are no "private repositories" in GitHub nor SmalltalkHub and not everybody does open source software nor have servers on their own premises.
github private repos: https://github.com/plans smalltalkhub private repos: change the license to Private
I knew about github "paid" private repos. But I use https://bitbucket.org/ instead (it's free and I like it more). I didn't know about the private SmalltalkHub repos though. Thank you! Esteban A. Maringolo 2013/9/13 Paul DeBruicker <pdebruic@gmail.com>:
On 09/13/2013 08:50 AM, Esteban A. Maringolo wrote:
But there are no "private repositories" in GitHub nor SmalltalkHub and not everybody does open source software nor have servers on their own premises.
github private repos: https://github.com/plans
smalltalkhub private repos: change the license to Private
participants (7)
-
btc＠openinworld.com -
Esteban A. Maringolo -
GOUBIER Thierry -
Goubier Thierry
-
Paul DeBruicker -
phil＠highoctane.be -
Stéphane Ducasse