On 10/24/06, Daniel L. Rall <dlr@collab.net> wrote:
> Dan, while working with Madan on his recent 'copy' patch to handle
> implied merge info for copy source paths, we've run into some
> problems, illustrated by 'merge_tests.py 12' and the attached patch.
> An abbreviated example follows:
>
> # Copy /A (at r1), creating a new path with merge info of /A:1 for r2
> svn cp file:///repos-path/A file:///repos-path/copy-of-A
>
> # Notice that even though A has an implied merge info of /A:1-3, that
> # diff is unaware
> svn diff file:///repos-path/copy-of-A_at_2 file:///repos-path/A_at_3
> Property changes on: .
> ___________________________________________________________________
> Name: svn:mergeinfo
> - /A:1
>
> # Merge reports ' G', a property change for "svn:mergeinfo"
> svn merge file:///repos-path/copy-of-A_at_2 file:///repos-path/A_at_3 A
> G A
>
> # However, the merge didn't actually change the merge info --
> # 'propget' still shows nothing
> svn pg svn:mergeinfo A
>
> If we consider implied merge info when doing the property diff in
> libsvn_repos/delta.c (where it calls svn_prop_diffs()), we might send
> an inappropriate prop delta back to the WC, resulting in us not
> recording explicit merge info when we should be. If we discard merge
> info for our own path within libsvn_wc, we might also toss explicit
> merge info which we should record (possibly important when doing
> bi-directional merging back into the branch where the merge info
> originally came from).
Right, but remember the paramount goal is to not get incorrectness,
even if it means we lose merge info.
>
>
> When I described this problem on IRC, Michael Haggerty had some
> thoughts on the design (and its impact on the above case). The
> beginning of our discussion went off the end of my scroll buffer
> (possibly logged on the net somewhere), but I thought you might be
> interested anyways. He seems to really be in favor of a more
> ancestry-based approach, which could certainly help with some of the
> problems we're running into. (If he can find the time, Michael
> indicated that he'd try and summarize the discussion below.)
>
I'm generally in favor of ancestry based approaches (mainly because
i'm a graph algorithms person), and if i believe it would not require
a huge massive amount of work, i would have done it.
:)
The sad fact is that we don't transfer the information necessary
through the RA and FS layer right now.
I was asked to give a design that would give us the functionality of
svnmerge.py and then a little more. I will happily admit it will fall
down in complex cases, because I know it will.
If you want to make something that can pretty much merge anything into
anything else, well, that's a different design :)
To do Michael's scheme (which is really just what any FS that knows
the different between merge and change would do, it's really quite a
common scheme) you need to be able to differentiate between changes
made to files because of merges, and changes made otherwise.
We can't.
Doing so would require modifying the WC layer, the RA layer, and the
FS layer, so they could distinguish this. This is really non-trivial
work.
I'm happy to agree that if we were to do that, you'd be able to
handle much more complex merges.
However, I disagree that if we start with this now, it becomes
impossible to use something else later or to migrate to something else
later. The only thing that happens is that you have to heuristically
guess some info, and be conservative at it, which means sometimes you
will end up with more conflicts than you would had you started using
the scheme in the first place.
We already have this situation now.
It all depends on what level of functionality you want at a first
pass. I've *always* said i expect to do something different at a
later point in time. I see this point in time as 2.0, not 1.5.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 26 01:58:01 2006