FileTree Monticello Repository

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 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.

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 <[hidden email]>

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.