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? -- View this message in context: http://forum.world.st/Git-filetree-workflow-tp4701465.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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? -- View this message in context: http://forum.world.st/Git-filetree-workflow-tp4701465p4701466.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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 :
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?
-- View this message in context: http://forum.world.st/Git-filetree-workflow-tp4701465.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- 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? -- View this message in context: http://forum.world.st/Git-filetree-workflow-tp4701465p4701503.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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-squeaksour... 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? -- 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.
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 :
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.
-- 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
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? -- View this message in context: http://forum.world.st/Git-filetree-workflow-tp4701465p4701651.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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? -- View this message in context: http://forum.world.st/Git-filetree-workflow-tp4701465p4701734.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On Wed, Jul 31, 2013 at 6:27 PM, joerick <joerick@mac.com> wrote:
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.
Hi, sorry for the delay:
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?
Pharo 2 image comes with Fuel already loaded. It's fuel 1.9, so you might need to migrate your fuel files, or to load another fuel version. MartÃn
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 <joerick@mac.com> 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.
participants (4)
-
Goubier Thierry -
joerick -
Martin Dias -
Stéphane Ducasse