You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2005/06/25 04:53:08 UTC
Re: svn commit: r15164 - trunk/notes
On Fri, 2005-06-24 at 15:08 -0500, sussman@tigris.org wrote:
> + old-baseprops target-baseprops
> + | |
> + | (server-propsets) | (localedit-propsets)
> + | |
> + v v
> + new-baseprops workingprops
> + if PROPNAME doesn't exist in target-baseprops:
> + else: /* PROPNAME exists in target-baseprops */
> + if (value of PROPNAME in target-baseprops) != FROM:
I feel like you're ignoring the result of the IRC discussion, and making
target-baseprops part of the merge. (That is, you're creating a
four-way merge algorithm instead of a three-way one involving just
old-baseprops, new-baseprops, and workingprops.) That's not consistent
with how we handle text.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff3 merging behaviors (was Re: svn commit: r15164 - trunk/notes)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 27, 2005, at 3:20 PM, Greg Hudson wrote:
>
> I guess the potentially disturbing thing here is that the local mods
> have not necessarily been recorded yet, and can be lost as a result of
> the merge operation. But why would I be doing a merge on top of local
> mods in the first place? Generally, I'd only do that if I were
> doing a
> sequence of merge commands, such as if I were creating a 1.2 backport
> branch. In that case, I would be pretty frustrated if the text
> base got
> in the way of performing a clean merge.
>
OK, I think I can sleep soundly, our current diff3 algorithm is fine.
If you look at the property-merging file in notes/, I've rewritten
the pseudocode algorithm to completely ignore the text-base-props.
I'd be happy if you folks would give it a quick sanity check.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff3 merging behaviors (was Re: svn commit: r15164 -
trunk/notes)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-06-27 at 11:54 -0500, Ben Collins-Sussman wrote:
> cmpilato and I were discussing a scenario where the server wants to
> change a single line of text from A to C, and in the working copy,
> the text-base is Q, with a local mod that changes it to A.
>
> Amazingly, 'svn merge' overwrites the existing local-mod as a clean
> merge. 'svn diff' then shows Q changing into C. The original local-
> mod is gone; reverting takes the line back to Q, rather than A.
>
> Is this a known behavior? Is it bad?
Well, it's certainly what I would expect. "svn diff" sees that the
common ancestor and one target (the wc copy) have 'A', and the other
target (the merge target) has 'C'.
I'm not sure why the text base is necessarily important. If a previous
revision changed A to Q and another previous revision changed Q back to
A, we wouldn't expect the merge to pay any heed.
I guess the potentially disturbing thing here is that the local mods
have not necessarily been recorded yet, and can be lost as a result of
the merge operation. But why would I be doing a merge on top of local
mods in the first place? Generally, I'd only do that if I were doing a
sequence of merge commands, such as if I were creating a 1.2 backport
branch. In that case, I would be pretty frustrated if the text base got
in the way of performing a clean merge.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff3 merging behaviors
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> cmpilato and I were discussing a scenario where the server wants to
> change a single line of text from A to C, and in the working copy,
> the text-base is Q, with a local mod that changes it to A.
>
> Amazingly, 'svn merge' overwrites the existing local-mod as a clean
> merge. 'svn diff' then shows Q changing into C. The original local-
> mod is gone; reverting takes the line back to Q, rather than A.
I haven't been following the discussion, but that merge behaviour
strikes me as perfectly reasonable. Consider the 1.2.x STATUS file:
* r15157, r15175
Fix Issue #2343: svn_io_copy_dir_recursively is broken
Justifcation:
Prevents a rather simple operation from completing if the
source path contains the same name as the destination.
Notes:
r15175 is a small formatting fix.
Votes:
+1: jszakmeister
+1: kfogel (r15157 only)
The second revision will only apply on top of the local mods produced
by the first revision.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
diff3 merging behaviors (was Re: svn commit: r15164 - trunk/notes)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 27, 2005, at 11:08 AM, Ben Collins-Sussman wrote:
>
> Rather than get ourselves all tangled in merge-tracking design, I
> think I'll just imitate this behavior when merging properties. We
> can always get more sophisticated later on.
>
Hm, things are uglier than I suspected with our current diff3 text-
merging.
cmpilato and I were discussing a scenario where the server wants to
change a single line of text from A to C, and in the working copy,
the text-base is Q, with a local mod that changes it to A.
Amazingly, 'svn merge' overwrites the existing local-mod as a clean
merge. 'svn diff' then shows Q changing into C. The original local-
mod is gone; reverting takes the line back to Q, rather than A.
Is this a known behavior? Is it bad?
It definitely points to what ghudson theorized: that our diff3
algorithm is *completely* ignoring the text-base.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r15164 - trunk/notes
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 25, 2005, at 9:25 AM, Greg Hudson wrote:
>
>> The algorithm above suggests that because the two starting
>> values
>> (A and C) are unequal, we should flag a conflict. But our
>> current
>> diff3 algorithm on lines-of-text may actually not care about the
>> target base; it might produce a smooth merge because the
>> *results*
>> are the same.
>>
>
> One possible justification for this behavior is that the text-base of
> the working copy can be seen as an arbitrary intermediate point in
> time.
> It's not necessarily the repository head revision, even; it's just
> what
> you happened to have checked out. (Although you'll get an out-of-date
> error on checkin if it's not the head, I suppose.)
>
> Even if we were going to make Subversion do four-way text merges using
> variance-adjusted patching, I'm not sure that the working copy text
> base
> would be part of any merges. I think the fourth point would come from
> merge-tracking information.
I just verified that in the case of a single line of text, the text-
base is indeed ignored in our 4-way scenario. 'svn merge' produces a
simple 'G', as my footnote hypothesized it might.
Rather than get ourselves all tangled in merge-tracking design, I
think I'll just imitate this behavior when merging properties. We
can always get more sophisticated later on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r15164 - trunk/notes
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2005-06-25 at 08:39 -0500, Ben Collins-Sussman wrote:
> Aha, well I did add a footnote to the document right after the IRC
> conversation, take a look.
Ah, sorry I didn't read carefully enough.
> The algorithm above suggests that because the two starting values
> (A and C) are unequal, we should flag a conflict. But our current
> diff3 algorithm on lines-of-text may actually not care about the
> target base; it might produce a smooth merge because the *results*
> are the same.
One possible justification for this behavior is that the text-base of
the working copy can be seen as an arbitrary intermediate point in time.
It's not necessarily the repository head revision, even; it's just what
you happened to have checked out. (Although you'll get an out-of-date
error on checkin if it's not the head, I suppose.)
Even if we were going to make Subversion do four-way text merges using
variance-adjusted patching, I'm not sure that the working copy text base
would be part of any merges. I think the fourth point would come from
merge-tracking information.
As long as we're talking about this aspect of merging, people should be
aware at some level of Bram Cohen's work described in
http://lists.zooko.com/pipermail/revctrl/ (it's a low-traffic list; look
for stuff about the new Codeville merge algorithm starting in May).
He's working on a merge algorithm which doesn't assume anything about
common ancestors, because one of the goals is to address the
"criss-cross merge" corner case described at
http://www.gelato.unsw.edu.au/archives/git/0504/2279.html . The
criss-crose merge case is apparently pretty common with cooperative
distributed development; the reason it doesn't come up so much in
Subversion and CVS is that you have to do a local merge with the head
before commit, and the repository doesn't bother to store what you had
before that merge. Bram is also providing "implicit rollback", meaning
that you don't have to tell the revision control system that you're
rejecting or rolling back a patch in order to make the merge algorithm
do the right thing. This seems to conflict with another desirable
property called "patch convergence", though. I'm also not sure whether
Bram's algorithm requires different inputs to the merge than Subversion
can provide, and whether it can be implemented with the required
performance characteristics.
darcs has also put substantial work into the text merge problem, as I
understand it. And then there's this variance-adjusted patching which
Sander put into libsvn_diff but which we don't use yet; perhaps that is
another way to address the criss-cross merge case. Merging makes my
head hurt, so I'm not sure how all these pieces fit together.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r15164 - trunk/notes
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 24, 2005, at 11:53 PM, Greg Hudson wrote:
>
> I feel like you're ignoring the result of the IRC discussion, and
> making
> target-baseprops part of the merge. (That is, you're creating a
> four-way merge algorithm instead of a three-way one involving just
> old-baseprops, new-baseprops, and workingprops.) That's not
> consistent
> with how we handle text.
Aha, well I did add a footnote to the document right after the IRC
conversation, take a look. It addresses this very subject, regarding
the exact codepath you quoted:
### FOOTNOTE:
Our 'svn merge' diagram really suggests using a diff4 algorithm,
rather than diff3.
What should we do in the case of a server-propset attempting to
change PROPNAME from A to B, while the user has locally changed
the same PROPNAME from C to B?
The algorithm above suggests that because the two starting values
(A and C) are unequal, we should flag a conflict. But our current
diff3 algorithm on lines-of-text may actually not care about the
target base; it might produce a smooth merge because the *results*
are the same.
Need to discuss this more. What does our textual diff3 actually
do? And is it a good thing to imitate?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org