Re: [Gnu-arch-users] help, now what?

[Jeremy Shaw]

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.