On 10/25/06, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> What do people think of this?
Hi Michael,
Currently, svnmerge.py tracks direct merge information, but it does
not keep track of indirect merge information. If you merge from A->B,
and then from B->C, svnmerge won't realise that changes from A were
merged to C.
Your proposal to track "novel changes" is well thought out. I think
that this proposal will solve our problems with indirect merges.
In your proposal, you track novel changes on a per-branch basis. I
think that we should take your proposal a step further and track novel
changes on a per-file basis.
If I make changes to two files in a single commit (let's say I changed
README.txt, and INSTALL.txt), I have made two novel changes. If I
merge (or copy) the trunk README.txt onto a branch, the branch will
have my README.txt change, but it won't have my INSTALL.txt change. We
need to keep track of this information.
In February, I made a very similar proposal, which assigned
"change_id" numbers to each novel change to each file. When files are
copied (or merged), these "change_id" numbers are copied, too. You can
find my old proposal at
http://svn.haxx.se/dev/archive-2006-02/0701.shtml
My old proposal is a bit inefficient for large repositories, because
it keeps individual change_ids which are associated with every copy of
every file. When you copy a file, the merge tracking information needs
to be copied, too. Unfortunately, my old proposal does not support
lazy copies, so some space (and time) is wasted when you branch. (The
current merge-tracking branch does not support lazy copies of merge
tracking metadata, either, so it is similarly inefficient.)
To keep Subversion performing well when you have lots of branches,
you'll need to support lazy copies of merge-tracking metadata. I've
already outlined a proposal for doing this. See
http://svn.haxx.se/dev/archive-2006-05/0061.shtml
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 26 03:09:55 2006