Hello, I am working with Sebastian on some code and we tried out filetree:// We have our packages saved there on disk and then we commit/push them on the git server. Now, as we develop and then need to merge, I find it hard to do those merges on the .st files. As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines. What is the current best practice for merging packages that way? TIA Phil
Have you tried this? https://github.com/ThierryGoubier/GitFileTree-MergeDriver Not sure about the ^M problem though... Johan On 27 May 2014, at 20:38, phil@highoctane.be wrote:
Hello,
I am working with Sebastian on some code and we tried out filetree://
We have our packages saved there on disk and then we commit/push them on the git server.
Now, as we develop and then need to merge, I find it hard to do those merges on the .st files.
As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines.
What is the current best practice for merging packages that way?
TIA Phil
2014-05-27 20:41 GMT+02:00 Johan Brichau <johan@inceptive.be>:
Have you tried this?
https://github.com/ThierryGoubier/GitFileTree-MergeDriver
Not sure about the ^M problem though...
Johan
I second this, with GitFileTree it solves most problems of false conflicts caused by MC metadata. For true conflicts, I did not inquire.
On 27 May 2014, at 20:38, phil@highoctane.be wrote:
Hello,
I am working with Sebastian on some code and we tried out filetree://
We have our packages saved there on disk and then we commit/push them on the git server.
Now, as we develop and then need to merge, I find it hard to do those merges on the .st files.
As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines.
What is the current best practice for merging packages that way?
TIA Phil
On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-05-27 20:41 GMT+02:00 Johan Brichau <johan@inceptive.be>:
Have you tried this?
https://github.com/ThierryGoubier/GitFileTree-MergeDriver
Not sure about the ^M problem though...
Johan
I second this, with GitFileTree it solves most problems of false conflicts caused by MC metadata. For true conflicts, I did not inquire.
Ok, will have a look. At first sight, it looks scary and less friendly than a plain old MCZ merge. But... git is the standard and it is painful to have to maintain things in two places... Phil
On 27 May 2014, at 20:38, phil@highoctane.be wrote:
Hello,
I am working with Sebastian on some code and we tried out filetree://
We have our packages saved there on disk and then we commit/push them on the git server.
Now, as we develop and then need to merge, I find it hard to do those merges on the .st files.
As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines.
What is the current best practice for merging packages that way?
TIA Phil
On 27 May 2014, at 17:09, phil@highoctane.be wrote:
On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2014-05-27 20:41 GMT+02:00 Johan Brichau <johan@inceptive.be>: Have you tried this?
https://github.com/ThierryGoubier/GitFileTree-MergeDriver
Not sure about the ^M problem though...
Johan
I second this, with GitFileTree it solves most problems of false conflicts caused by MC metadata. For true conflicts, I did not inquire.
Ok, will have a look.
At first sight, it looks scary and less friendly than a plain old MCZ merge.
But... git is the standard and it is painful to have to maintain things in two placesâ¦
filetree format is buggy when merging. Reason is is keeping monticello metadata and that does not plays very good with git (bah, it does not play good at all). We are working (Max is doing some work there) in a better integration with git, where we can drop all those metadata files and rely on git information (it is there, we just need to use it). But as always, things needs time and time is scarce :(. My recommendation in the mean time is to try gitfiletree. There is a good chance that it fixes your problems. Esteban
Phil
On 27 May 2014, at 20:38, phil@highoctane.be wrote:
Hello,
I am working with Sebastian on some code and we tried out filetree://
We have our packages saved there on disk and then we commit/push them on the git server.
Now, as we develop and then need to merge, I find it hard to do those merges on the .st files.
As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines.
What is the current best practice for merging packages that way?
TIA Phil
2014-05-27 22:19 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 27 May 2014, at 17:09, phil@highoctane.be wrote:
On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-05-27 20:41 GMT+02:00 Johan Brichau <johan@inceptive.be>:
Have you tried this?
https://github.com/ThierryGoubier/GitFileTree-MergeDriver
Not sure about the ^M problem though...
Johan
I second this, with GitFileTree it solves most problems of false conflicts caused by MC metadata. For true conflicts, I did not inquire.
Ok, will have a look.
At first sight, it looks scary and less friendly than a plain old MCZ merge.
But... git is the standard and it is painful to have to maintain things in two placesâ¦
filetree format is buggy when merging. Reason is is keeping monticello metadata and that does not plays very good with git (bah, it does not play good at all).
As long as the metadata (package ancestry, commit comments, ...) is kept into the image, it plays remarkably well. Good enough to help maintaining Squeak and Pharo projects for ten years or so, as well as a few others (croquet/cobalt, etoys, the VM, etc...) Everything into the image is such a simple model that Pharo now want the whole source in the image rather than in a file, no ;) Yes, these metadata are growing, but I'm pretty sure that this simple model can scale for a few more years. I agree that MC has a problem at server side with files, files make an awfull database! But alternate solutions exist (like magma). MC has another problem with IDs (GUID were not appended to file names, I really don't know why). For packaging an artefact made of several Smalltalk packages, the simplicity of MonticelloConfiguration (MCM) as used in Squeak rocks (simple tools for simple tasks). For me, git make sense for other reasons - mixed language development (like the VM) - visibility, social/collaborative tools like github (pull request, code reviews etc...) - very efficient branching (but it's a false assumption that MC can't do branching, it's more that MCM can't) Git is very powerfull, efficient, light, scales very well, it's from far the best option available for SCM... But in term of simplicity, please think twice for the next generation of in image tools, MC rocks, I wish you invent something as simple and efficient. Nicolas We are working (Max is doing some work there) in a better integration with
git, where we can drop all those metadata files and rely on git information (it is there, we just need to use it). But as always, things needs time and time is scarce :(.
My recommendation in the mean time is to try gitfiletree. There is a good chance that it fixes your problems.
Esteban
Phil
On 27 May 2014, at 20:38, phil@highoctane.be wrote:
Hello,
I am working with Sebastian on some code and we tried out filetree://
We have our packages saved there on disk and then we commit/push them on the git server.
Now, as we develop and then need to merge, I find it hard to do those merges on the .st files.
As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines.
What is the current best practice for merging packages that way?
TIA Phil
On Tue, May 27, 2014 at 1:19 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
On 27 May 2014, at 17:09, phil@highoctane.be wrote:
On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-05-27 20:41 GMT+02:00 Johan Brichau <johan@inceptive.be>:
Have you tried this?
https://github.com/ThierryGoubier/GitFileTree-MergeDriver
Not sure about the ^M problem though...
Johan
I second this, with GitFileTree it solves most problems of false conflicts caused by MC metadata. For true conflicts, I did not inquire.
Ok, will have a look.
At first sight, it looks scary and less friendly than a plain old MCZ merge.
But... git is the standard and it is painful to have to maintain things in two placesâ¦
filetree format is buggy when merging. Reason is is keeping monticello metadata and that does not plays very good with git (bah, it does not play good at all).
Well intentionally buggy ... the only reason that the meta data is included in the filetree repo is to play nicely with Monticello - the metadata is required if one expects to copy mcz files into and out of filetree repositories ... it is possible to adopt mcz versions, biut I decided that I would be painfully backward compatible with monticello rather than deal with the chaos that would ensue if one were REQUIRED to adopt the correct versions ... When you yank the monticello meta data you have become committed to using the git repository and that can't be done until the level of tool support in the dev environement is up to snuff ... We are working (Max is doing some work there) in a better integration with
git, where we can drop all those metadata files and rely on git information (it is there, we just need to use it). But as always, things needs time and time is scarce :(.
My recommendation in the mean time is to try gitfiletree. There is a good chance that it fixes your problems.
Yep, Thierry has done some real good work! Dale
Le 27/05/2014 22:19, Esteban Lorenzano a écrit :
On 27 May 2014, at 17:09, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote:
2014-05-27 20:41 GMT+02:00 Johan Brichau <johan@inceptive.be <mailto:johan@inceptive.be>>:
Have you tried this?
https://github.com/ThierryGoubier/GitFileTree-MergeDriver
Not sure about the ^M problem though...
Johan
I second this, with GitFileTree it solves most problems of false conflicts caused by MC metadata. For true conflicts, I did not inquire.
Ok, will have a look.
At first sight, it looks scary and less friendly than a plain old MCZ merge.
But... git is the standard and it is painful to have to maintain things in two placesâ¦
filetree format is buggy when merging. Reason is is keeping monticello metadata and that does not plays very good with git (bah, it does not play good at all).
This is in no part due to the fact that we don't set up git to play nice with this metadata...
We are working (Max is doing some work there) in a better integration with git, where we can drop all those metadata files and rely on git information (it is there, we just need to use it). But as always, things needs time and time is scarce :(.
Yes. I'm expecting a lot from that project, even if I'm not sure about that "removing the metadata" stuff. Using git as the source of the metadata isn't hard.
My recommendation in the mean time is to try gitfiletree. There is a good chance that it fixes your problems.
It has issues with the merge conflicts, still. Hence the talk about the merge driver and the merge tool. 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
On 27 May 2014, at 22:09, phil@highoctane.be wrote:
Ok, will have a look.
At first sight, it looks scary and less friendly than a plain old MCZ merge.
But... git is the standard and it is painful to have to maintain things in two places...
I'm testing the 'git for smalltalk' workflow in the context of our team because we really want the flexible branching which is non existent in MC. If you want to have continuous release, a single trunk repository is not cutting it. Git is good at that and the availability of things like github/travis/pull requests etc... is also a big plus, although it certainly is a lot more complex than mcz. The GitFiletree mergedriver takes away a lot of the burden when working with the filetree format. It is a big step forward but imho it will only be truly used when git is integrated with the Smalltalk IDE for real. It works well once you get the hang of it but there are many manual things to take care of, which is why I'm still reluctant to introduce it fully in our development flow because making mistakes can easily lead to lost code, wrong version history, wrong merges, etc... So, for now, we use it for experimental branches and we do a manual merge back into a monticello repository when it needs to go into production. De l'expérimentation quoi.. ;-) Johan
On Tue, May 27, 2014 at 11:12 PM, Johan Brichau <johan@inceptive.be> wrote:
On 27 May 2014, at 22:09, phil@highoctane.be wrote:
Ok, will have a look.
At first sight, it looks scary and less friendly than a plain old MCZ merge.
But... git is the standard and it is painful to have to maintain things in two places...
I'm testing the 'git for smalltalk' workflow in the context of our team because we really want the flexible branching which is non existent in MC. If you want to have continuous release, a single trunk repository is not cutting it. Git is good at that and the availability of things like github/travis/pull requests etc... is also a big plus, although it certainly is a lot more complex than mcz.
Agreed. We are using GitLab and it rocks! Add to that that a chunk of the application has nothing to do with Smalltalk and is using Bash, Php, and whatnot to get the things done. Git is also great to deploy the stuff on multiple machines.
The GitFiletree mergedriver takes away a lot of the burden when working with the filetree format. It is a big step forward but imho it will only be truly used when git is integrated with the Smalltalk IDE for real.
It works well once you get the hang of it but there are many manual things to take care of, which is why I'm still reluctant to introduce it fully in our development flow because making mistakes can easily lead to lost code, wrong version history, wrong merges, etc...
Yes, at the moment we save to filetree:// to have a trace in git but the real merge work happens in a MC Repo (FTP w/ user&password), which works nicely enough.
So, for now, we use it for experimental branches and we do a manual merge back into a monticello repository when it needs to go into production.
De l'expérimentation quoi.. ;-)
I am with you on that. Git is complicated enough without embarking of weird scenarios like that. But for teamwork, this is invaluable. Phil
Johan
Johan,
From the GemStone side, tODE has a number of git-friendly features and will be available for alpha real-soon-now[TM] ...
I use the tODE git merge tool for all of my git merges as I consider it superior to the existing mergetools out there ... but then I'm biased:) I'm willing to share the fundamental classes for parsing the git merge/diff information if folks from Pharo want to get into that business ... the Metacello Preview features have also been aimed at support for git-based development and I'm leveraging those features for tODE as well ... Dale On Tue, May 27, 2014 at 2:12 PM, Johan Brichau <johan@inceptive.be> wrote:
On 27 May 2014, at 22:09, phil@highoctane.be wrote:
Ok, will have a look.
At first sight, it looks scary and less friendly than a plain old MCZ merge.
But... git is the standard and it is painful to have to maintain things in two places...
I'm testing the 'git for smalltalk' workflow in the context of our team because we really want the flexible branching which is non existent in MC. If you want to have continuous release, a single trunk repository is not cutting it. Git is good at that and the availability of things like github/travis/pull requests etc... is also a big plus, although it certainly is a lot more complex than mcz.
The GitFiletree mergedriver takes away a lot of the burden when working with the filetree format. It is a big step forward but imho it will only be truly used when git is integrated with the Smalltalk IDE for real.
It works well once you get the hang of it but there are many manual things to take care of, which is why I'm still reluctant to introduce it fully in our development flow because making mistakes can easily lead to lost code, wrong version history, wrong merges, etc...
So, for now, we use it for experimental branches and we do a manual merge back into a monticello repository when it needs to go into production.
De l'expérimentation quoi.. ;-)
Johan
Le 27/05/2014 23:48, Dale Henrichs a écrit :
Johan,
From the GemStone side, tODE has a number of git-friendly features and will be available for alpha real-soon-now[TM] ...
I use the tODE git merge tool for all of my git merges as I consider it superior to the existing mergetools out there ... but then I'm biased:)
I'm willing to share the fundamental classes for parsing the git merge/diff information if folks from Pharo want to get into that business ...
Cool. I'm for it :)
the Metacello Preview features have also been aimed at support for git-based development and I'm leveraging those features for tODE as well ...
Dale
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
Hi Phil, Le 27/05/2014 20:38, phil@highoctane.be a écrit :
Hello,
I am working with Sebastian on some code and we tried out filetree://
We have our packages saved there on disk and then we commit/push them on the git server.
Now, as we develop and then need to merge, I find it hard to do those merges on the .st files.
As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines.
On which platform are you commiting / merging ? This looks strange: .st files should be multi-line, not one line.
What is the current best practice for merging packages that way?
As others said, probably the best is the GitFileTree-MergeDriver to minimize conflicts with FileTree Monticello metadata, but I'd say it's complex to setup at the moment, and the git mergetool that Dale has in ToDe (to avoid using meld :)) I'm trying to find the time to document and set a sample git repo in the PharoForTheEnterprise book with all the different ways to merge: - pure FileTree - FileTree + GitFileTree merge driver - GitFileTree + binary merge on metadata - GitFileTree + GitFileTree merge driver But I'm not finding the time I need to finish that :( I'll be presenting that during the next MooseDay, so it can be an occasion to talk. 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
2014-05-28 10:44 GMT+02:00 Goubier Thierry <thierry.goubier@cea.fr>:
Hi Phil,
Le 27/05/2014 20:38, phil@highoctane.be a écrit :
Hello,
I am working with Sebastian on some code and we tried out filetree://
We have our packages saved there on disk and then we commit/push them on the git server.
Now, as we develop and then need to merge, I find it hard to do those merges on the .st files.
As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines.
On which platform are you commiting / merging ? This looks strange: .st files should be multi-line, not one line.
I've patched MC model (MethodDefinition and class comments) with a few withSqueakLineEndings (sorry Pharoers for the Squeakism) to just ignore the line ending differences. Maybe I should publish, but my feeling was that there should be a better place (upstream) for this...
What is the current best practice for merging packages that way?
As others said, probably the best is the GitFileTree-MergeDriver to minimize conflicts with FileTree Monticello metadata, but I'd say it's complex to setup at the moment, and the git mergetool that Dale has in ToDe (to avoid using meld :))
I'm trying to find the time to document and set a sample git repo in the PharoForTheEnterprise book with all the different ways to merge:
- pure FileTree - FileTree + GitFileTree merge driver - GitFileTree + binary merge on metadata - GitFileTree + GitFileTree merge driver
But I'm not finding the time I need to finish that :(
I'll be presenting that during the next MooseDay, so it can be an occasion to talk.
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
Hi Thierry, On Wed, May 28, 2014 at 10:44 AM, Goubier Thierry <thierry.goubier@cea.fr>wrote:
Hi Phil,
Le 27/05/2014 20:38, phil@highoctane.be a écrit :
Hello,
I am working with Sebastian on some code and we tried out filetree://
We have our packages saved there on disk and then we commit/push them on the git server.
Now, as we develop and then need to merge, I find it hard to do those merges on the .st files.
As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines.
On which platform are you commiting / merging ? This looks strange: .st files should be multi-line, not one line.
CentOS 6 Linux
What is the current best practice for merging packages that way?
As others said, probably the best is the GitFileTree-MergeDriver to minimize conflicts with FileTree Monticello metadata, but I'd say it's complex to setup at the moment, and the git mergetool that Dale has in ToDe (to avoid using meld :))
Yeah, meld here... Or vimdiff
I'm trying to find the time to document and set a sample git repo in the PharoForTheEnterprise book with all the different ways to merge:
- pure FileTree - FileTree + GitFileTree merge driver - GitFileTree + binary merge on metadata - GitFileTree + GitFileTree merge driver
But I'm not finding the time I need to finish that :(
Mmmh, anything not even close to a draft and some notes are welcome!
I'll be presenting that during the next MooseDay, so it can be an occasion to talk.
Yeah, I think that I can come over for the first day to listen you that Git talk of yours and show you our thing. BTW http://www.doesnotunderstand.org/MOOSEDayUPMC/ says "Thuesday". I do not know what "Thuesday" means, but as the next day looks like "Friday", I'd advise someone put "Thursday" (or is it Tuesday after all?). Schedule Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam. looks weird too. Phil
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 28/05/2014 11:16, phil@highoctane.be a écrit :
Hi Thierry,
On Wed, May 28, 2014 at 10:44 AM, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>> wrote:
On which platform are you commiting / merging ? This looks strange: .st files should be multi-line, not one line.
CentOS 6 Linux
Well, have you set any strange options in the git repository itself? I've seen in the man pages stuff about automatic line ending conversions.
What is the current best practice for merging packages that way?
As others said, probably the best is the GitFileTree-MergeDriver to minimize conflicts with FileTree Monticello metadata, but I'd say it's complex to setup at the moment, and the git mergetool that Dale has in ToDe (to avoid using meld :))
Yeah, meld here... Or vimdiff
At least there is a tool :)
I'm trying to find the time to document and set a sample git repo in the PharoForTheEnterprise book with all the different ways to merge:
- pure FileTree - FileTree + GitFileTree merge driver - GitFileTree + binary merge on metadata - GitFileTree + GitFileTree merge driver
But I'm not finding the time I need to finish that :(
Mmmh, anything not even close to a draft and some notes are welcome!
I haven't yet set it to generates the chapter, but it is the GitAndPharo chapter (and I have a GitAndPharoTutorial repository on github to go along, with pre-prepared branches to let people experiment the merge).
I'll be presenting that during the next MooseDay, so it can be an occasion to talk.
Yeah, I think that I can come over for the first day to listen you that Git talk of yours and show you our thing.
Cool. It'll be a pleasure :) Thierry
BTW http://www.doesnotunderstand.org/MOOSEDayUPMC/ says "Thuesday". I do not know what "Thuesday" means, but as the next day looks like "Friday", I'd advise someone put "Thursday" (or is it Tuesday after all?).
Schedule
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam.
looks weird too.
Phil
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 <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 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
participants (6)
-
Dale Henrichs -
Esteban Lorenzano -
Goubier Thierry -
Johan Brichau -
Nicolas Cellier -
phil＠highoctane.be