On 10/25/06, David James <djames@collab.net> wrote:
> 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.
You need to be careful how far you go, or else you will get into an
insane amount of bookkeeping and comparison.
>
> 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
Doing this very efficiently requires FS changes, and even more RA/WC
changes (you'd have to track the "isresultofmerge" on a per-file basis
in the WC). You are going to have to change every
add/delete/merge/apply_textdelta FS operation to have a flag saying
whether it is the result of a merge or not, so you know whether it is
part of a novel change or not.
None of this is impossible, it's just a large amount of work.
It also requires either some pretty hairy db schemas, or built-in fs support.
This is one reason I started looking at revlog format, which
explicitly supports per-file parents (and could be trivially extended
to differentiate merge-parents from non-merge parents, and then it
would be explicitly representing the information you are looking for.
You'd then be able to simply walk up the file tree to get the "novel
change" information for a single file.
I think it's great that you guys want to do all this. Really. One of
the original design goals was to have something one or two people
could implement for 1.5, and get us the functionality of svnmerge.py.
Unless people are willing to commit to helping with these schemes,
they just aren't time feasible for a single minor version, IMHO.
It's very easy to come up with better designs than what we've got. It
was not built to support complex merges, just the very simple merge
back and forth between a branch and a trunk. As I said on IRC, I
had a design like Michael's, but threw it out because it was too much
work for a single minor version time frame. If ya'll want to use
Michael's instead of what we got now, I ain't gonna take any offense,
but i'm not sure it's the right answer for 1.5.
I'd be more than happy to be proven wrong of course.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 26 15:51:39 2006