[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Saving merge history

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-08-13 00:01:56 CEST

William Uther wrote:

> 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).
> 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.

Do you want to just recreate the sequence of merge commands, or just
record enough information to generate _equivalent_ merge commands? Your
solution is sufficient for the first case, but it wastes space in
general. For example:

    $ svn merge -r1:4 branch trunk
    $ svn merge -r3:7 branch trunk

With your solution, svn:merged on trunk/* would look like this:

    branch 1:4
    branch 3:7

A more compact representation, that would give the same result (as far
as we know without finer granulation!) would merge those ranges into

    branch 1:7

That's what I'd propose: svn:merge contains one line per merge source
(filesystem path, not URL), with a compressed list of relevant ranges.
After a more complex set of merges:

    $ svn merge -r1:4 foo trunk
    $ svn merge -r3:4 bar trunk
    $ svn merge -r3:4 qux trunk
    $ svn merge -r7:12 foo trunk
    $ svn merge -r4:8 qux trunk

you'd get:

    bar 3:4
    foo 1:4 7:12
    qux 3:8

> 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.

Are you certain that would be enough to "fix" 'svn log' for you? I'm
asking because I don't know the details of how 'svn log' follows copy
history. I certainly don't see a problem with this, but I'd like to see
comments from our Schema King first.

> At the moment I'm waiting to see how issue #838 resolves, because that
> affects how change ii) would be made.

Fixing #838 will involve changing the use of svn_client_copy (back) to
svn_wc_add (with history), for now. Bill Tutt proposed a change in the
way CopyIDs are produced for merges and lazy copies, but that would
entail a pretty big libsvn_fs change, and I'm not sure it's worth it.

Anyway, I fail to see how #838 affects (ii), because the semantics
(e.g., merge does a copy behind the scenes) must remain, IMNSHO.

> Do you still think this is not enough information?

I suppose this could be a workable first step, yes. Care to write the
spec, and implement it? :-)

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 00:02:34 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.