At Sat, 17 Sep 2005 15:51:54 -0700, Thomas Lord wrote: > `git' flows from Linus' personal requirements and so branching and > cherry-picking are not high on the priority list. There is enough > momentum (last I checked) in the group of people competing to hack > `git' and `git'-derivatives that I would guess that will eventually > change. (`revc' doesn't *contain* the solution you want there > as it stands but I laid down that foundation with such needs in > mind. It shouldn't be hard to build full and improved tla-style > merging on top of it.)
I was thinking about this a bit last night, and I think recv could possibly have far superior merging capabilities to tla. (Note: the following may be old news to some people, but it was new to me :p ) I have not looked into recv too closely yet, but my impression is that when you change a file, recv saves the entire changed file in the commit. This means later, when you try to merge one version of the file into another, you are working with whole files, not diffs. The advantage is, you can use any tool you want to perform the actual file content merging -- recv does not have to know anything about how the merging of individual files is done. (It does, of course, still need to keep track of ancestory, renames, etc). In the past, many people have asked for tla to support special kinds of 'diffs' for formats that don't always work cleanly with standard context diffs -- such as xml files. The objection has always been that other people do not want to have to install all sorts of special patching tools just to check out or work with someone else's tree. Because recv does not store the changes -- just the 'before' and 'after' -- it seems like each user ought to be able to provide their own custom rules and tools for merging files, without requiring anyone else using the archive to also have those tools. I envision each merge tool would just take (as a minimum) three arguments, for example: xml-merge ancestor.xml version1.xml version2.xml [output.xml] One big advantage of this is that the merging tools and recv can be developed orthagonally. It is also interesting to note that the exact same merge will succeed for some people, but fail for other people depending on what merge tools they have installed[1]. This is not a bad thing, since it does not affect their ability to check out any specific version, or interoperate with each other. I also suspect that this method could be wedged on top of something like tla -- though it may be very slow, since you need to first create ancestor.xml, version1.xml and version2.xml. However, well populated revision libraries should give you very fast access to the three versions of the file. Of course, I could realize I am grossly mistaken, once I get a little sleep. Jeremy Shaw. [1] For example, if I have an xml-merge tool installed, then a given merge may succeed for me. If you do not have the xml-merge tool installed, then the merge may try to patch/diff instead, and fail. If it fails, it just means you have to resolve the conflicts by hand. The end result will likely be the same or very similar in both cases. _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
