On Monday, August 12, 2002, at 07:50 AM, brane@xbc.nu wrote:
> Quoting William Uther <will+@cs.cmu.edu>:
>> The proposed change saves enough information to re-create the original
>> merge command to svn. What else does 'real changesets' require?
>
> You have to be able to track individual diff hunks, not just whole
> files. For
> example, after a merge each diff hunk in the merge candidates can be in
> one of
> the following states:
[snip - states]
Okie - I see this as internal to the delta combiner. I don't see why we
need to store merge information on this level.
> What you propose only gives you "merged" and "ignored" info for whole
> file contents.
Er, it gives you enough to recreate the original svn command line, and
hence enough to do anything else. Unless you are planning to save
information about exactly how the user resolved conflicts (more than
just looking at the result of that resolution, which you have), then
this has all the information.
>> I don't see that tracking individual diff
>> hunks is necessary though - just a modified form of the delta combiner
> ^^^^
>
> Oh, right. You're absolutely right. A changeset engine _is_ a modified
> form of
> the delta combiner. The trouble is that the "just" happens to hide a
> slightly
> huge amount of work. :-)
I agree that USING this information is a lot of work. And there is
quite possibly a format that would help that. That is post-1.0 though.
>> If you don't save merge history now, even given that you don't use it
>> in
>> 1.0, then you are losing information. The logs on those copied dirs
>> are
>> never going to be correct if you don't save the merge information now.
>> If there is an easy way to save that information, and even if we end up
>> re-formatting it later, saving it would seem to be a good thing.
>
> Hm, that is a good point. In fact, I'm inclined to say this point is
> more
> important than getting 'svn log' "right" (for some definition of
> "right" -- I
> think it's more right to show too many logs than to show too few, witch
> is so
> not right that it's wrong :-).
I'm all for storing more information. There are currently three
different "log formats": The original, the current, and the one
described in Issue #820. I think the current format is better than the
one before the copy-with-history patch. I think the Issue #820 one is
better still (It doesn't lose any information, and adds consistency).
> Let's talk about this a bit more, then.
To sum up the changes I think we need to make to store merge info (in
O(1) space):
i) Files that are modified during a merge get a line added to their
svn:merged property. This stores enough to re-create the command line.
ii) Files/Dirs that are copied during a merge get a "merge" line in the
copies table, not a "copy" line. Pre-1.0 these two could be treated
identically, although that would change post-1.0. (see
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=19798)
To make part ii) work, the difference between a merge and a copy needs
to be added to the wire protocol somewhere to get the information back
to the server, and the dump/load format needs to change to record the
difference between the two types of copies.
At the moment I'm waiting to see how issue #838 resolves, because that
affects how change ii) would be made.
Do you still think this is not enough information?
later,
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 12 21:38:30 2002