merging in a filetree repository
Locked
12
12
 
|
Hi!
Do I still need to press the merge button in Monticello when I am working on a filtree git repository? I understand that no since the merging has to be done by Git, and not by monticello. I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json Why do we need this methodProperties.json and version files? Shouldn’t git handle this? How should I merge these files? Any experience? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: merging in a filetree repository
|
|
Hi Alex, I've been troubled by this some time ago, so Thierry and Dale gave me exhaustive explanation here http://forum.world.st/Metacello-GIT-methodProperties-json-td4818097.html As for merging via git, there is also mentioned MergeDriver that's very easy to use and should be able to resolve most problems. Peter On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <[hidden email]> wrote: Hi! |
|
|
Thanks Peter, I will have a look…
Alexandre > On Jul 8, 2015, at 12:31 PM, Peter Uhnák <[hidden email]> wrote: > > Hi Alex, > > I've been troubled by this some time ago, so Thierry and Dale gave me exhaustive explanation here http://forum.world.st/Metacello-GIT-methodProperties-json-td4818097.html > > As for merging via git, there is also mentioned MergeDriver that's very easy to use and should be able to resolve most problems. > > Peter > > On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <[hidden email]> wrote: > Hi! > > Do I still need to press the merge button in Monticello when I am working on a filtree git repository? > I understand that no since the merging has to be done by Git, and not by monticello. > > I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: > > CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version > CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json > CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json > > Why do we need this methodProperties.json and version files? Shouldn’t git handle this? > > How should I merge these files? Any experience? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: merging in a filetree repository
|
|
In reply to this post by Peter Uhnak
Yurij post also an explanation recently here:
http://code.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.html On Wed, Jul 8, 2015 at 12:31 PM, Peter Uhnák <[hidden email]> wrote: > Hi Alex, > > I've been troubled by this some time ago, so Thierry and Dale gave me > exhaustive explanation here > http://forum.world.st/Metacello-GIT-methodProperties-json-td4818097.html > > As for merging via git, there is also mentioned MergeDriver that's very easy > to use and should be able to resolve most problems. > > Peter > > On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <[hidden email]> > wrote: >> >> Hi! >> >> Do I still need to press the merge button in Monticello when I am working >> on a filtree git repository? >> I understand that no since the merging has to be done by Git, and not by >> monticello. >> >> I tried to not do the merge in monticello, but I get some conflicts when >> doing the git merge. For example: >> >> CONFLICT (content): Merge conflict in >> Hackathon.package/monticello.meta/version >> CONFLICT (content): Merge conflict in >> Hackathon.package/HProject.class/methodProperties.json >> CONFLICT (content): Merge conflict in >> Hackathon.package/HClass.class/methodProperties.json >> >> Why do we need this methodProperties.json and version files? Shouldn’t git >> handle this? >> >> How should I merge these files? Any experience? >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ |
Re: merging in a filetree repository
|
|
> On 08 Jul 2015, at 12:46, Serge Stinckwich <[hidden email]> wrote: > > Yurij post also an explanation recently here: > http://code.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.html That link does not seem to work ... > > On Wed, Jul 8, 2015 at 12:31 PM, Peter Uhnák <[hidden email]> wrote: >> Hi Alex, >> >> I've been troubled by this some time ago, so Thierry and Dale gave me >> exhaustive explanation here >> http://forum.world.st/Metacello-GIT-methodProperties-json-td4818097.html >> >> As for merging via git, there is also mentioned MergeDriver that's very easy >> to use and should be able to resolve most problems. >> >> Peter >> >> On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <[hidden email]> >> wrote: >>> >>> Hi! >>> >>> Do I still need to press the merge button in Monticello when I am working >>> on a filtree git repository? >>> I understand that no since the merging has to be done by Git, and not by >>> monticello. >>> >>> I tried to not do the merge in monticello, but I get some conflicts when >>> doing the git merge. For example: >>> >>> CONFLICT (content): Merge conflict in >>> Hackathon.package/monticello.meta/version >>> CONFLICT (content): Merge conflict in >>> Hackathon.package/HProject.class/methodProperties.json >>> CONFLICT (content): Merge conflict in >>> Hackathon.package/HClass.class/methodProperties.json >>> >>> Why do we need this methodProperties.json and version files? Shouldn’t git >>> handle this? >>> >>> How should I merge these files? Any experience? >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > |
|
|
In reply to this post by abergel
We have a .gitignore file that contains:
version methodProperties.json So, we don't bother. The side effects of this are: Without methodProperties.json, you have the default author and meaningless timestamp. Without the version file, loading does not work properly. So we have a script that generates version files for each package before we load into the image. At first, this script counted versions for the package and got all the info from the git repository. But this was too expensive (because the file system became slow when traversing the git repo to find the meta data). So now, we just generate a version file with a fixed author, date & time now and a UUID & version number derived from the SHA1 of the .package directory. We get all the meta-information directly from the git repo, using git tools. This can be better with GitFileTree. So we really just use basics of Monticello & Metacello and do the rest externally from the image. We need to explore the available tools more. On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <[hidden email]> wrote: > Hi! > > Do I still need to press the merge button in Monticello when I am working on a filtree git repository? > I understand that no since the merging has to be done by Git, and not by monticello. > > I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: > > CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version > CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json > CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json > > Why do we need this methodProperties.json and version files? Shouldn’t git handle this? > > How should I merge these files? Any experience? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > |
|
|
This is frustrating….
I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver And I got: ~/HackathonSattose2015> git merge master pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory fatal: Failed to execute internal merge Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing…. Maybe I will go back to Smalltalkhub afterall… Alexandre > On Jul 8, 2015, at 2:21 PM, Otto Behrens <[hidden email]> wrote: > > We have a .gitignore file that contains: > version > methodProperties.json > > So, we don't bother. > > The side effects of this are: > Without methodProperties.json, you have the default author and > meaningless timestamp. > Without the version file, loading does not work properly. So we have a > script that generates version files for each package before we load > into the image. At first, this script counted versions for the package > and got all the info from the git repository. But this was too > expensive (because the file system became slow when traversing the git > repo to find the meta data). So now, we just generate a version file > with a fixed author, date & time now and a UUID & version number > derived from the SHA1 of the .package directory. > > We get all the meta-information directly from the git repo, using git > tools. This can be better with GitFileTree. > > So we really just use basics of Monticello & Metacello and do the rest > externally from the image. We need to explore the available tools > more. > > On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel > <[hidden email]> wrote: >> Hi! >> >> Do I still need to press the merge button in Monticello when I am working on a filtree git repository? >> I understand that no since the merging has to be done by Git, and not by monticello. >> >> I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: >> >> CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version >> CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json >> CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json >> >> Why do we need this methodProperties.json and version files? Shouldn’t git handle this? >> >> How should I merge these files? Any experience? >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
Our “coding” atoms are methods, not classes. Having method per file we can trace the history of changes with method detail, not class.
Now… you are complaining in the wrong problem. FileTree meta information (who causes your merge problems) is needed *just* to keep monticello compatibility. That’s what is plain wrong and should be at least optional :) I would happily integrate a “PlainFileTree” protocol (without monticello information) as an option, if someone provides such extension. Crap, I could make it myself if I have the time!… maybe next insomnia night :P Esteban > On 08 Jul 2015, at 14:51, Alexandre Bergel <[hidden email]> wrote: > > This is frustrating…. > > I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver > And I got: > > ~/HackathonSattose2015> git merge master > pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory > fatal: Failed to execute internal merge > > Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing…. > > Maybe I will go back to Smalltalkhub afterall… > > Alexandre > > >> On Jul 8, 2015, at 2:21 PM, Otto Behrens <[hidden email]> wrote: >> >> We have a .gitignore file that contains: >> version >> methodProperties.json >> >> So, we don't bother. >> >> The side effects of this are: >> Without methodProperties.json, you have the default author and >> meaningless timestamp. >> Without the version file, loading does not work properly. So we have a >> script that generates version files for each package before we load >> into the image. At first, this script counted versions for the package >> and got all the info from the git repository. But this was too >> expensive (because the file system became slow when traversing the git >> repo to find the meta data). So now, we just generate a version file >> with a fixed author, date & time now and a UUID & version number >> derived from the SHA1 of the .package directory. >> >> We get all the meta-information directly from the git repo, using git >> tools. This can be better with GitFileTree. >> >> So we really just use basics of Monticello & Metacello and do the rest >> externally from the image. We need to explore the available tools >> more. >> >> On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel >> <[hidden email]> wrote: >>> Hi! >>> >>> Do I still need to press the merge button in Monticello when I am working on a filtree git repository? >>> I understand that no since the merging has to be done by Git, and not by monticello. >>> >>> I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: >>> >>> CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version >>> CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json >>> CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json >>> >>> Why do we need this methodProperties.json and version files? Shouldn’t git handle this? >>> >>> How should I merge these files? Any experience? >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > |
Re: merging in a filetree repository
|
|
In reply to this post by abergel
2015-07-08 14:51 GMT+02:00 Alexandre Bergel <[hidden email]>: This is frustrating…. Looks like a problem when installing the merge driver. pathToGitFileTree-MergeDriver shoudl not appear like that, so it seems the make used to install wasn't successful. Can you show the result of $ git config --get merge.mcVersion.driver
FileTree is a standardised format, cross-smalltalk compatible, browsable on github, with a nice set of tests to make sure it keeps working across many revisions of Squeak, Gemstone and Pharo.
Up to you ;) Thierry
|
Re: merging in a filetree repository
|
|
In reply to this post by abergel
On 08-07-15 14:51, Alexandre Bergel wrote:
> This is frustrating…. > > Maybe I will go back to Smalltalkhub afterall… Git support is still bleeding edge. Why did you want to move away from smalltalkhub before we have libgit2 integrated? Stephan |
|
|
In reply to this post by EstebanLM
> Our “coding” atoms are methods, not classes. Having method per file we can trace the history of changes with method detail, not class.
That I understand. > Now… you are complaining in the wrong problem. Well… Having one file per method seems to be very problematic after all. > FileTree meta information (who causes your merge problems) is needed *just* to keep monticello compatibility. > That’s what is plain wrong and should be at least optional :) > > I would happily integrate a “PlainFileTree” protocol (without monticello information) as an option, if someone provides such extension. > Crap, I could make it myself if I have the time!… maybe next insomnia night :P We can work on this next week. I am fed up to hear “why you guys are not using github?" Alexandre > >> On 08 Jul 2015, at 14:51, Alexandre Bergel <[hidden email]> wrote: >> >> This is frustrating…. >> >> I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver >> And I got: >> >> ~/HackathonSattose2015> git merge master >> pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory >> fatal: Failed to execute internal merge >> >> Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing…. >> >> Maybe I will go back to Smalltalkhub afterall… >> >> Alexandre >> >> >>> On Jul 8, 2015, at 2:21 PM, Otto Behrens <[hidden email]> wrote: >>> >>> We have a .gitignore file that contains: >>> version >>> methodProperties.json >>> >>> So, we don't bother. >>> >>> The side effects of this are: >>> Without methodProperties.json, you have the default author and >>> meaningless timestamp. >>> Without the version file, loading does not work properly. So we have a >>> script that generates version files for each package before we load >>> into the image. At first, this script counted versions for the package >>> and got all the info from the git repository. But this was too >>> expensive (because the file system became slow when traversing the git >>> repo to find the meta data). So now, we just generate a version file >>> with a fixed author, date & time now and a UUID & version number >>> derived from the SHA1 of the .package directory. >>> >>> We get all the meta-information directly from the git repo, using git >>> tools. This can be better with GitFileTree. >>> >>> So we really just use basics of Monticello & Metacello and do the rest >>> externally from the image. We need to explore the available tools >>> more. >>> >>> On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel >>> <[hidden email]> wrote: >>>> Hi! >>>> >>>> Do I still need to press the merge button in Monticello when I am working on a filtree git repository? >>>> I understand that no since the merging has to be done by Git, and not by monticello. >>>> >>>> I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: >>>> >>>> CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version >>>> CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json >>>> CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json >>>> >>>> Why do we need this methodProperties.json and version files? Shouldn’t git handle this? >>>> >>>> How should I merge these files? Any experience? >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: merging in a filetree repository
|
|
In reply to this post by otto
Hi Otto,
2015-07-08 14:21 GMT+02:00 Otto Behrens <[hidden email]>: We have a .gitignore file that contains: This is a bit drastic :)
GitFileTree only derives the UUID from the SHA1 of the .package directory. It derives the version number from the number of versions in the git commit history.
This is what GitFileTree does, with a crafted command for git log ;). I'm interested in the "performance" issue reading versions from the git history you mention above. If you had the time to try with just installing GitFileTree and opening the repository, and checking: if it is slow, and if it gives you the right history. So we really just use basics of Monticello & Metacello and do the rest This is one way to do it ;) Thierry |
|
|
In reply to this post by Thierry Goubier
> Looks like a problem when installing the merge driver.
> > pathToGitFileTree-MergeDriver shoudl not appear like that, so it seems the make used to install wasn't successful. Can you show the result of > > $ git config --get merge.mcVersion.driver ~/HackathonSattose2015> git config --get merge.mcVersion.driver pathToGitFileTree-MergeDriver/merge --version %O %A %B > Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing…. > > FileTree is a standardised format, cross-smalltalk compatible, browsable on github, with a nice set of tests to make sure it keeps working across many revisions of Squeak, Gemstone and Pharo. Okay, but we all agree this is very far from an ideal solution right? Also, if I understand correctly, at each new repository I need to create a file .gitattributes : *.package/monticello.meta/version merge=mcVersion *.package/*.class/methodProperties.json merge=mcMethodProperties *.package/*.class/properties.json merge=mcProperties *.package/*.extension/methodProperties.json merge=mcMethodProperties *.package/*.extension/properties.json merge=mcProperties Alexandre > > > > On Jul 8, 2015, at 2:21 PM, Otto Behrens <[hidden email]> wrote: > > > > We have a .gitignore file that contains: > > version > > methodProperties.json > > > > So, we don't bother. > > > > The side effects of this are: > > Without methodProperties.json, you have the default author and > > meaningless timestamp. > > Without the version file, loading does not work properly. So we have a > > script that generates version files for each package before we load > > into the image. At first, this script counted versions for the package > > and got all the info from the git repository. But this was too > > expensive (because the file system became slow when traversing the git > > repo to find the meta data). So now, we just generate a version file > > with a fixed author, date & time now and a UUID & version number > > derived from the SHA1 of the .package directory. > > > > We get all the meta-information directly from the git repo, using git > > tools. This can be better with GitFileTree. > > > > So we really just use basics of Monticello & Metacello and do the rest > > externally from the image. We need to explore the available tools > > more. > > > > On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel > > <[hidden email]> wrote: > >> Hi! > >> > >> Do I still need to press the merge button in Monticello when I am working on a filtree git repository? > >> I understand that no since the merging has to be done by Git, and not by monticello. > >> > >> I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: > >> > >> CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version > >> CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json > >> CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json > >> > >> Why do we need this methodProperties.json and version files? Shouldn’t git handle this? > >> > >> How should I merge these files? Any experience? > >> > >> Cheers, > >> Alexandre > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Stephan Eggermont-3
I just wanted to give a try.
Alexandre > On Jul 8, 2015, at 3:08 PM, Stephan Eggermont <[hidden email]> wrote: > > On 08-07-15 14:51, Alexandre Bergel wrote: >> This is frustrating…. >> >> Maybe I will go back to Smalltalkhub afterall… > > Git support is still bleeding edge. > Why did you want to move away from smalltalkhub > before we have libgit2 integrated? > > Stephan > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: merging in a filetree repository
|
|
In reply to this post by abergel
2015-07-08 15:11 GMT+02:00 Alexandre Bergel <[hidden email]>: > Our “coding” atoms are methods, not classes. Having method per file we can trace the history of changes with method detail, not class. It's not ;)
It's extremely easy to do. Most of the code is ready for it. But since there is no real push to get Pharo under git for now, I've left it as it is. In part because some are using FileTree directly and they need that compatibility level. Thierry |
|
|
In reply to this post by Thierry Goubier
Most of our problems here is because we insist on being interchangeable between git and mcz.
While treating git as “just another repository” can feel appealable in certain cases (for example, in the super-uncommon way of handle vm building we have, when we use git and Eliot uses squeak source, then we are kind of a mirror), this is not the most common usage: if you start a project on git, you are expected other contributors use git too… same as in any other SVC tool (there is not compatibility between SVN, HG, GIT, etc.) Of course, it looked like a good idea at the beginning, but now I think is counterproductive (is the kind of ideas that are great at the beginning because it provides security/confortability to users, but with time demonstrate obsolete). What we actually need is tools that can load configurations from different sources (for example, I have a project in git who uses seaside and I want a configuration who loads both…). But… guess what? WE ALREADY HAVE IT!!!! Metacello is perfectly capable of doing that. Gofer is capable of doing that. Heck, even monticello is capable of doing that as long as we do not pretend their are interchangeable! So, again… what we actually need is to accept reality: we do not need all that metadata in 99% of cases! Esteban
|
|
|
In reply to this post by abergel
Thierry,
>> $ git config --get merge.mcVersion.driver > > ~/HackathonSattose2015> git config --get merge.mcVersion.driver > pathToGitFileTree-MergeDriver/merge --version %O %A %B Any idea how I can merge then? Is this value what you expected? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: merging in a filetree repository
|
|
In reply to this post by abergel
2015-07-08 15:15 GMT+02:00 Alexandre Bergel <[hidden email]>: > Looks like a problem when installing the merge driver. Then this means the make in GitFileTree-MergeDriver hasn't worked. When you did the make, what was the output? > Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing…. No, I disagree. I have been using it in production for the past 4 years, under conditions and constraints that Smalltalkhub and mcz can't handle (and never will).
Yes, only once. As you will setup also a .gitignore. You'll notice that some of the github hosted Pharo repositories already have that file set. Regards, Thierry
|
|
|
In reply to this post by Thierry Goubier
you’re wrong :) I feel the pain each time I need to provide a “we are not ready yet”. As I said… real reason we are not ready is because we are still trying to mix to words, in ways no one actually needs. So please… push! Esteban ps: and btw… there is no reason why we cannot keep “mc-file-tree” along with a “plain-file-tree” both alive. As I said… I just can image very few cases when we *actually* need that compatibility.
|
|
|
In reply to this post by Thierry Goubier
> Then this means the make in GitFileTree-MergeDriver hasn't worked. When you did the make, what was the output?
It is: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ~/Dropbox/Workspace/GitFileTree-MergeDriver> make mkdir pharo cd pharo; wget -O- get.pharo.org/30+vm | bash --2015-07-08 14:20:12-- http://get.pharo.org/30+vm Resolving get.pharo.org... 128.93.162.72 Connecting to get.pharo.org|128.93.162.72|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2901 (2.8K) [text/html] Saving to: 'STDOUT' - 100%[=====================>] 2.83K --.-KB/s in 0s 2015-07-08 14:20:12 (146 MB/s) - written to stdout [2901/2901] Downloading the latest 30 Image: http://files.pharo.org/get-files/30/pharo.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/get-files/30/pharo-mac-stable.zip pharo-vm/Pharo.app/Contents/MacOS/Pharo Downloading PharoV30.sources: http://files.pharo.org/get-files/30/sources.zip Creating starter scripts pharo and pharo-ui pharo/pharo pharo/Pharo.image --no-default-preferences eval --save Gofer new url: \'http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main/\'\; package: \'GitFileTree-MergeDriver\'\; load a GoferLoad git config --global merge.mcVersion.driver "`pwd`/merge --version %O %A %B" git config --global merge.mcMethodProperties.name "GitFileTree MergeDriver for Monticello" git config --global merge.mcMethodProperties.driver "`pwd`/merge --methodProperties %O %A %B" git config --global merge.mcProperties.name "GitFileTree MergeDriver for Monticello" git config --global merge.mcProperties.driver "`pwd`/merge --properties %O %A %B" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Please help :-) Alexandre > > Okay, but we all agree this is very far from an ideal solution right? > > No, I disagree. > > I have been using it in production for the past 4 years, under conditions and constraints that Smalltalkhub and mcz can't handle (and never will). > > > Also, if I understand correctly, at each new repository I need to create a file .gitattributes : > > *.package/monticello.meta/version merge=mcVersion > *.package/*.class/methodProperties.json merge=mcMethodProperties > *.package/*.class/properties.json merge=mcProperties > *.package/*.extension/methodProperties.json merge=mcMethodProperties > *.package/*.extension/properties.json merge=mcProperties > > Yes, only once. > > As you will setup also a .gitignore. > > You'll notice that some of the github hosted Pharo repositories already have that file set. > > Regards, > > Thierry > > > Alexandre > > > > > > > > > On Jul 8, 2015, at 2:21 PM, Otto Behrens <[hidden email]> wrote: > > > > > > We have a .gitignore file that contains: > > > version > > > methodProperties.json > > > > > > So, we don't bother. > > > > > > The side effects of this are: > > > Without methodProperties.json, you have the default author and > > > meaningless timestamp. > > > Without the version file, loading does not work properly. So we have a > > > script that generates version files for each package before we load > > > into the image. At first, this script counted versions for the package > > > and got all the info from the git repository. But this was too > > > expensive (because the file system became slow when traversing the git > > > repo to find the meta data). So now, we just generate a version file > > > with a fixed author, date & time now and a UUID & version number > > > derived from the SHA1 of the .package directory. > > > > > > We get all the meta-information directly from the git repo, using git > > > tools. This can be better with GitFileTree. > > > > > > So we really just use basics of Monticello & Metacello and do the rest > > > externally from the image. We need to explore the available tools > > > more. > > > > > > On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel > > > <[hidden email]> wrote: > > >> Hi! > > >> > > >> Do I still need to press the merge button in Monticello when I am working on a filtree git repository? > > >> I understand that no since the merging has to be done by Git, and not by monticello. > > >> > > >> I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: > > >> > > >> CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version > > >> CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json > > >> CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json > > >> > > >> Why do we need this methodProperties.json and version files? Shouldn’t git handle this? > > >> > > >> How should I merge these files? Any experience? > > >> > > >> Cheers, > > >> Alexandre > > >> > > >> -- > > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > >> Alexandre Bergel http://www.bergel.eu > > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >> > > >> > > >> > > >> > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |