Git filetree workflow

I work on a project that uses smalltalk as a part of a larger system. We version control most of the code (Objective-C, mainly) using Git. Currently the repo has a build script under version control which specifies the monticello package versions to fetch for a given commit. This works okay, and keeps everything in step, but the change histories are in two places (Git and monticello) which is undesirable, and branching/merging is difficult.

I'm looking at using filetree (https://github.com/dalehenrich/filetree) to store the smalltalk source in the git repo. I was wondering what the workflow is within the image.

Is there an easy way to keep the code on the filesystem in sync with the code in the image? At the moment it seems that there will be a lot of loading/saving in the monticello browser whenever I change code either using git or within the image.

For example, do I have to save code out to the filesystem using the Monticello browser, and then inspect the diffs in git?

Furthermore, I just had a poke around the filetree of a package, and found the `monticello.meta/version` file. This seems to contain information on the monticello commits. Do I need this? I'd rather only have git commit messages. Perhaps this file could be ignored by git?

Hi,

I have been working in a similar setup for more than a year. I used
filetree, with the problem you describe (double code maintenance both in
git and in Monticello, which often resulted in lost Monticello versions
in the git history). You also have the fact that, when you merge under
git, most often than note the monticello.meta/version file will generate
a conflict.

So I added a better git support to filetree, calling it gitfiletree://.
It's integrated into (https://github.com/dalehenrich/filetree) with the
following workflow :
* When you save under Monticello, you commit with git with a comment
which is your Monticello comment.
* When you open your gitfiletree repo in Monticello, what you see is
your git history filtered by the package (ancestors and all), not the
Monticello history (i.e. if you modify or merge outside smalltalk, it
will show up in Monticello), and not the full git repo history.
* The version and other metadata stuff will probably cause merge
conflicts, but gitfiletree never reads them anymore : all the package
info data (author, timestamp, comments, history) is taken from the git
commit history.
* Monticello diffs will be the same as in git, without the metadata noise.

Otherwise, it's filetree compatible (you can read your HEAD with
filetree), and it integrates with Gofer well (you can import a mcz based
repository into git, keeping the history).

The current MonticelloFileTree configuration has a
MonticelloFileTree-Git group to load it.

If there are things in the Workflow you'd like to see, then this can be
implemented.

Thierry

Le 30/07/2013 12:03, joerick a écrit :
--
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,

Many thanks for your prompt reply! I did find gitfiletree on smalltalk hub while I was doing some research, but I thought that filetree was specifically designed to be used with git, so I tried that first.

I'll see how it works in my case. Just one question- how do I import the mcz history into git?

Le 30/07/2013 14:51, joerick a écrit :
> Thierry,
>
> Many thanks for your prompt reply! I did find gitfiletree on smalltalk hub
> while I was doing some research, but I thought that filetree was
> specifically designed to be used with git, so I tried that first.

Filetree works with a bit more than git; it should work with svn, cvs,
mercurial, etc.. anything which does version control over files.

Gitfiletree is filetree plus calls to the "git" command (git commit, git
log, git archive, git branch) and the consequences...

> I'll see how it works in my case. Just one question- how do I import the mcz
> history into git?

You use one of the Gofer scripts you will find for migrating from one
repository to another [1]:

Gofer it
squeaksource: 'Fuel';
package: 'Fuel';
package: 'FuelTests';
fetch.

Gofer it
url: 'http://ss3.gemstone.com/ss/Fuel';
package: 'Fuel';
package: 'FuelTests';
push.

[1]
http://marianopeck.wordpress.com/2011/11/08/migrating-projects-to-squeaksource3/

But do that with as target a gitfiletree repo, not a filetree one;
gitfiletree will do a commit for each version of a project pushed to it;
filetree will overwrite the previous version. You will loose the mcz
timestamps however.

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

Oh, I'm having trouble adding a gitfiletree repository, do you support Pharo 1.4?

Sorry no, only 2.0. I wonder if, however, it could work...

What are the errors you're getting?

Thierry

Le 30/07/2013 16:41, joerick a écrit :
--
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

We know that changing version can be painful but just consider that you are working with a nearly 3 years old system.

stef

On Jul 30, 2013, at 4:41 PM, joerick <[hidden email]> wrote:

> Oh, I'm having trouble adding a gitfiletree repository, do you support Pharo
> 1.4?
>
>
>
> --
> View this message in context: http://forum.world.st/Git-filetree-workflow-tp4701465p4701541.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

I'm getting a DNU for UnixFileDirectory on #pathString.

Additionally, I tried the Gofer #push command with the basic filetree:// with multiple packages but it failed to save a few and didn't raise an error. A bit unsettling... filetree is supposed to be 1.4 compatible, yes?

Le 31/07/2013 11:52, joerick a écrit :
> I'm getting a DNU for UnixFileDirectory on #pathString.

Yes. I made a try yesterday and it failed on FileDirectory instead of
FileReference (pathString is one of the FileReference method) and also
on a Date readFrom: bug. From that, it seems feasible to do a one off
(take a recent gitfiletree version and make a mcz adapted by force to
Pharo1.4) but harder to reintegrate those adaptations in a proper way
inside the filetree distribution.

> Additionally, I tried the Gofer #push command with the basic filetree://
> with multiple packages but it failed to save a few and didn't raise an
> error. A bit unsettling... filetree is supposed to be 1.4 compatible, yes?

Yes, I believe it is 1.4 compatible. Filetree is tested in integration
against Pharo1.4.

I don't know what the error is then. Can you try with multiple target
repositories in Filetree (subdirectories inside your git directory?)?

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

In the Gofer #push case, it's quite strange... some classes end up the wrong package, and some don't get output at all.

It seems to work using Gofer #push when each is in its own repository folder, and it also works with them all in the same folder when using Monticello Browser's 'save' button.

Perhaps I should try moving to 2.0. Last time we tried there was a package that hadn't been ported yet, I can't recall what it was... fuel perhaps?