> 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 <[email protected]> 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 <[email protected]> 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 >>> <[email protected]> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
