You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by John Goerzen <jg...@complete.org> on 2003/08/22 15:33:08 UTC
Merging confuses renamed files
Hi,
I've been playing around with Subversion's merging features and have
found that local changes get clobbered when a merge is run on a file.
Consider this example. We have Bob maintaining the main tree for
package foobar, and his repository is at http://foo.com/somewhere. He
maintains foo.py.
Alice has her own repository for foo.py, which contains a couple of
small changes.
She keeps it up to date with commands like:
svn merge -r 5:7 http://foo.com/somewhere .
svn commit -m 'Updated to r7'
...
svn merge -r 7:15 http://foo.com/somewhere .
svn commit -m 'Updated to r15'
Now, this all goes along happily. Alice's changes follow along as she
tracks the upstream development. But let's say that Bob does this:
svn mv foo.py bar.py
svn commit -m 'Renamed foo.py to bar.py' # Creates rev 17
Later, Candice updates with:
svn merge -r 15:20 http://foo.com/somewhere .
But her changes get lost. bar.py now contains the vanilla upstream,
rather than her patched version. And merge runs cleanly, never
warning of any problem.
My question is: why? Subversion has enough information to duplicate
the upstream changes locally, but doesn't. It appears to be behaving
as if --ignore-ancestry was given to merge, but it wasn't.
Can anybody shed some light on this?
Thanks,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by mark benedetto king <mb...@lowlatency.com>.
On Fri, Aug 22, 2003 at 12:57:41PM -0500, John Goerzen wrote:
> mark benedetto king <mb...@lowlatency.com> writes:
>
> >> Um ... Ben and I, kinda, made --ignore-ancestry the default. It's now
> >> --notice-ancestry. But the other day, Ben started having second
> >> thoughts, and now I am, too. Should this be reverted?
> >
> > If not, then the help message should be fixed.
> >
> > --notice-ancestry : ignore ancestry when calculating differences
>
> I am using 0.26.0, and svn merge --help does not mention
> --notice-ancestry at all. It only lists --ignore-ancestry. Was the
> change in that version lacking the corresponding change to the help
> text, or have I found a different bug here?
>
I have an in-between-0.26.0-0.27.0 svn client in my path. This is twice
now that I've reported problems not applicable to either release.
I'm going to "make install" now and double-check before opening my mouth
in the future.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by John Goerzen <jg...@complete.org>.
mark benedetto king <mb...@lowlatency.com> writes:
>> Um ... Ben and I, kinda, made --ignore-ancestry the default. It's now
>> --notice-ancestry. But the other day, Ben started having second
>> thoughts, and now I am, too. Should this be reverted?
>
> If not, then the help message should be fixed.
>
> --notice-ancestry : ignore ancestry when calculating differences
I am using 0.26.0, and svn merge --help does not mention
--notice-ancestry at all. It only lists --ignore-ancestry. Was the
change in that version lacking the corresponding change to the help
text, or have I found a different bug here?
-- John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by cm...@collab.net.
mark benedetto king <mb...@lowlatency.com> writes:
> On Fri, Aug 22, 2003 at 10:41:48AM -0500, cmpilato@collab.net wrote:
> > John Goerzen <jg...@complete.org> writes:
> >
> > > My question is: why? Subversion has enough information to duplicate
> > > the upstream changes locally, but doesn't. It appears to be behaving
> > > as if --ignore-ancestry was given to merge, but it wasn't.
> > >
> > > Can anybody shed some light on this?
> >
> > Um ... Ben and I, kinda, made --ignore-ancestry the default. It's now
> > --notice-ancestry. But the other day, Ben started having second
> > thoughts, and now I am, too. Should this be reverted?
>
> If not, then the help message should be fixed.
>
> --notice-ancestry : ignore ancestry when calculating differences
Um, get an updated client, homey.
$ svn help merge | grep notice
--notice-ancestry : notice ancestry when calculating differences
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Ben Collins-Sussman <su...@collab.net>.
mark benedetto king <mb...@lowlatency.com> writes:
> On Fri, Aug 22, 2003 at 10:41:48AM -0500, cmpilato@collab.net wrote:
> > John Goerzen <jg...@complete.org> writes:
> >
> > > My question is: why? Subversion has enough information to duplicate
> > > the upstream changes locally, but doesn't. It appears to be behaving
> > > as if --ignore-ancestry was given to merge, but it wasn't.
> > >
> > > Can anybody shed some light on this?
> >
> > Um ... Ben and I, kinda, made --ignore-ancestry the default. It's now
> > --notice-ancestry. But the other day, Ben started having second
> > thoughts, and now I am, too. Should this be reverted?
>
> If not, then the help message should be fixed.
>
> --notice-ancestry : ignore ancestry when calculating differences
That typo was fixed a couple of weeks ago. Are you running an old
svn?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by mark benedetto king <mb...@lowlatency.com>.
On Fri, Aug 22, 2003 at 10:41:48AM -0500, cmpilato@collab.net wrote:
> John Goerzen <jg...@complete.org> writes:
>
> > My question is: why? Subversion has enough information to duplicate
> > the upstream changes locally, but doesn't. It appears to be behaving
> > as if --ignore-ancestry was given to merge, but it wasn't.
> >
> > Can anybody shed some light on this?
>
> Um ... Ben and I, kinda, made --ignore-ancestry the default. It's now
> --notice-ancestry. But the other day, Ben started having second
> thoughts, and now I am, too. Should this be reverted?
If not, then the help message should be fixed.
--notice-ancestry : ignore ancestry when calculating differences
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Jack Repenning <jr...@collab.net>.
At 10:48 AM -0500 8/22/03, Ben Collins-Sussman wrote:
> * when you 'svn merge' the exact same change to your working copy,
> you *want* to see the intent of the change. It's important to
> see a "D foo, A foo" displayed -- don't cover up this fact by
> displaying "U foo". It's a piece of useful information.
>
>So my proposal is to do the least surprsing thing in each case: 'svn
>diff' should ignore ancestry by default, and 'svn merge' should honor
>ancestry by default. (Of course we'd have switches to allow opposite
>behaviors.)
>
>Any objections to this?
And now (in what may amount to bringing it full circle to John's
original question, if he really was working within one repo, or
thought Subversion really ought to be trans-repo-aware), I'll point
out that in this case, it is a merge going on, and yet it's exactly
the problem that history is being ignored: it's historically known
that Bob's old foo.py and his new bar.py are versions of the same
node. More precisely, since in Subversion (as in Unix) the name of a
file is actually a property of the directory, not of the file itself,
it's historically known that "the directory entry that used to be
named foo.py" on Bob's machine was linked to the same actual file
(node, or possibly even version) as "the directory entry now named
bar.py."
It's worth noting that this is an important difference between files
and directories: like most VC systems, Subversion does not control
the lines of a file, and really has no way to distinguish "change
this line" from "delete this line, add a new one in the same spot."
To do that, Subversion would have to infest the editor, an
unwholesome thought. But Subversion *does* manage the directory
entries, and it *does* know the difference between "rename this file"
and "delete this file, substitute a new one of a different name" (or
even "...substitute a new one of the same name"!). It may well be
that Subversion should behave differently on directories than on
files in this case: no SVN interface need ever say "delete foo; add
foo" if these foos are entries in a directory--unless of course
that's exactly what went on, in which case that's exactly what ought
to be said.
Another interesting difference between files and directories is that
directories have contents of diverse types--that is, files, and other
directories. If "foo" used to be (the name of) a file, and is now
(the name of a different object, which is) a directory, then there
was definitely some "delete/add" stuff going on here! But we don't
have any such idea for the contents of a file: they just contain
"stuff." If Subversion wants to "ignore history" in some diff or
merge context, and that means trying to present this change in a way
that isn't "delete/add," I anticipate some problems somewhere or
other.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by "Jamin W. Collins" <jc...@asgardsrealm.net>.
On Fri, Aug 22, 2003 at 10:48:48AM -0500, Ben Collins-Sussman wrote:
>
> Here's my thoughts, which I think cmpilato now agrees with:
>
> * when you run 'svn diff', you don't care *how* the change came
> into being, you just want to see the net result to your working
> copy . Seeing a "delete foo; add foo" is completely annoying
> and useless -- especially in unified diff output.
>
> * when you 'svn merge' the exact same change to your working copy,
> you *want* to see the intent of the change. It's important to
> see a "D foo, A foo" displayed -- don't cover up this fact by
> displaying "U foo". It's a piece of useful information.
>
> So my proposal is to do the least surprsing thing in each case: 'svn
> diff' should ignore ancestry by default, and 'svn merge' should honor
> ancestry by default. (Of course we'd have switches to allow opposite
> behaviors.)
>
> Any objections to this?
Sounds reasonable to me, but I'm only a user.
--
Jamin W. Collins
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> So my proposal is to do the least surprsing thing in each case: 'svn
> diff' should ignore ancestry by default, and 'svn merge' should honor
> ancestry by default. (Of course we'd have switches to allow opposite
> behaviors.)
>
> Any objections to this?
I disagree, I think diff and merge should behave the same. (I think
they should both honour ancestry by default, but that didn't appear to
be popular last time this was dicussed.)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Merging confuses renamed files
Posted by Sander Striker <st...@apache.org>.
> From: John Goerzen [mailto:jgoerzen@complete.org]
> Sent: Friday, August 22, 2003 10:11 PM
[...]
> I'm also saying "I *think* it could do this fairly trivially."
It's a hairy issue. Far from trivial.
>> I'm saying "it doesn't do this." I think you agree with that
>> ... that's what got you started!
>
> Indeed.
>
>> If the question is "why doesn't it do this?" then the answer is
>> "because it was not a design goal." Put another way, SVN is trying to
>> replace CVS, not Bitkeeper.
>
> I think that's a cop-out. To me, if merging destroys custom changes
> that should not be, with no warning, that is a bug.
To put Jacks words into other terms: at this point we have no one looking
into the fancy merging features. These are all post 1.0. Unless the
resources come along (read: volunteers) that work on merging, this isn't
going to happen anytime soon, certainly not pre 1.0.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by John Goerzen <jg...@complete.org>.
Jack Repenning <jr...@collab.net> writes:
> At 2:53 PM -0500 8/22/03, John Goerzen wrote:
>>
>>I don't quite follow your question, but I can state that from the
>>example, "." is *NOT* a working copy of http://foo.com/somewhere. It
>>could be a working copy at file:///home/alice/alicerepos.
Sorry, s/at/of/
> Wait, I'm all confused.
>
> So when you say "a working copy at file:///home/alice/alicerepos", I
> think you really mean "a repository there." Yes?
No, I mean a working copy *OF*. That is, the checked-out version.
> You're saying "it could do this." I agree with that.
I'm also saying "I *think* it could do this fairly trivially."
> I'm saying "it doesn't do this." I think you agree with that
> ... that's what got you started!
Indeed.
> If the question is "why doesn't it do this?" then the answer is
> "because it was not a design goal." Put another way, SVN is trying to
> replace CVS, not Bitkeeper.
I think that's a cop-out. To me, if merging destroys custom changes
that should not be, with no warning, that is a bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Jack Repenning <jr...@collab.net>.
At 2:53 PM -0500 8/22/03, John Goerzen wrote:
>
>I don't quite follow your question, but I can state that from the
>example, "." is *NOT* a working copy of http://foo.com/somewhere. It
>could be a working copy at file:///home/alice/alicerepos.
Wait, I'm all confused.
A "working copy" is the files you think you have, on your disk.
There are some .svn/ directories scattered about, that are
Subversion-specific stuff, but basically it's "your files"--your
foo.c and bar.html and whatever. We address the working copy by
simple file-name things like "foo.c" or "~/src/whatever."
A "repository" is the files on the *server*'s disk. It's a database:
it has contents with names like "db/" and "hooks/", regardless of
what files you have. We address things in the repository with URLs,
like "http://host/dir/dir/" or "file:///home/alice/whatever".
So when you say "a working copy at file:///home/alice/alicerepos", I
think you really mean "a repository there." Yes?
> > In that case, I think the answer to your question is "Subversion does
>> not maintain history between repositories." The fact that Sue's
>> foo.py once came from Bob's is not recorded; the merge only knows that
>> Bob has a "bar.py," and Sue does not.
>
>I understand that. But both the "before" and the "after" for the
>merge come from Bob and are being recorded in Sue's repository. That
>is, svn merge knows that this is a rename and -- even though it has no
>idea where the wc data originated -- should execute the same operation
>locally to apply it.
You're saying "it could do this." I agree with that.
I'm saying "it doesn't do this." I think you agree with that ...
that's what got you started!
If the question is "why doesn't it do this?" then the answer is
"because it was not a design goal." Put another way, SVN is trying
to replace CVS, not Bitkeeper.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by John Goerzen <jg...@complete.org>.
Jack Repenning <jr...@collab.net> writes:
> "His repository." "Her repository." Are you really talking about two
> separate repositories, John? Your examples are all from Sue's
> perspective, and refer to "her repository" only as ".". But if you
> really mean that she has a separate repository, then it must be named
> something like "http://foo.com/elsewhere", right?
I don't quite follow your question, but I can state that from the
example, "." is *NOT* a working copy of http://foo.com/somewhere. It
could be a working copy at file:///home/alice/alicerepos.
So yes, we are dealing with different repositories.
> In that case, I think the answer to your question is "Subversion does
> not maintain history between repositories." The fact that Sue's
> foo.py once came from Bob's is not recorded; the merge only knows that
> Bob has a "bar.py," and Sue does not.
I understand that. But both the "before" and the "after" for the
merge come from Bob and are being recorded in Sue's repository. That
is, svn merge knows that this is a rename and -- even though it has no
idea where the wc data originated -- should execute the same operation
locally to apply it.
At a slightly lower level, I know that a rename is an svn cp followed
by svn rm. Locally, it should svn cp foo.py bar.py and then svn rm
foo.py. This would preserve the local changes across renames.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Jack Repenning <jr...@collab.net>.
At 10:48 AM -0500 8/22/03, Ben Collins-Sussman wrote:
>cmpilato@collab.net writes:
>
>> John Goerzen <jg...@complete.org> writes:
>>
>> > My question is: why? Subversion has enough information to duplicate
>> > the upstream changes locally, but doesn't. It appears to be behaving
>> > as if --ignore-ancestry was given to merge, but it wasn't.
>> >
>> > Can anybody shed some light on this?
>>
>> Um ... Ben and I, kinda, made --ignore-ancestry the default. It's now
>> --notice-ancestry. But the other day, Ben started having second
>> thoughts, and now I am, too. Should this be reverted?
>
>Here's my thoughts, which I think cmpilato now agrees with:
Is this relevant to the original question?
At 10:33 AM -0500 8/22/03, John Goerzen wrote:
>Consider this example. We have Bob maintaining the main tree for
>package foobar, and his repository is at http://foo.com/somewhere. He
>maintains foo.py.
>
>Alice has her own repository for foo.py, which contains a couple of
>small changes.
"His repository." "Her repository." Are you really talking about
two separate repositories, John? Your examples are all from Sue's
perspective, and refer to "her repository" only as ".". But if you
really mean that she has a separate repository, then it must be named
something like "http://foo.com/elsewhere", right?
In that case, I think the answer to your question is "Subversion does
not maintain history between repositories." The fact that Sue's
foo.py once came from Bob's is not recorded; the merge only knows
that Bob has a "bar.py," and Sue does not.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Jack Repenning <jr...@collab.net>.
At 10:24 AM -0500 8/25/03, Ben Collins-Sussman wrote:
>Jack Repenning <jr...@collab.net> writes:
>
> > So: I think there is a distinction to be respected here, but it's not
>> "diff or merge" but "directory or file." In the file cases, I find
>> compelling precedent for a fairly complex behavior, some of which I
>> think you describe as "respecting history" and some as "ignoring it."
>
>There's no distinction between file or directory behavior.
>
>If a directory was deleted and then re-added, I would expect 'svn
>merge' to replay that exact bit of history: delete the whole tree,
>re-add it. If a file was deleted and re-added, I would expect the
>same behavior. I don't understand the "complex" behaviors that
>differentiate files and dirs... or maybe I do, but I don't follow you
>at the moment.
You missed my point. You have focused on directory-or-file as "the
thing added," while I am trying to draw attention to them as "the
place where something was added."
My point was that SVN can (has enough information), may (has no
conflicting precedents), and should (would be more usable, would be
clearer to the user) distinguish between "a change to a file itself"
and "a change to a directory itself." The behavior we're discussion
is "recursive diff"; its recursion means (among other things) that it
uses some of what it learned while examining a directory to modify
what it does with the contents it finds there. At the most trivial
level, it uses the list of contents as a modifier (definer, in fact)
of what contents there are. I suggest it also use the containing
directory's information about whether the same-named contents are
really the same object (versions of the same node).
SVN knows more about changes to directories than it does about
changes to files. If I transform this file:
line one
line two
line three
into this file
line one
line 2
line three
by deleting "line two" and inserting "line 2", or if I do it by
deleting only "two" and inserting "2", or if I do it be replacing
"two" with "2"--SVN has no slightest idea which approach I took.
But if I have a *directory* with three components of those names
(bizarre thought, but bear with the example, please), and make any
one of those changes, SVN knows exactly which course I took, because
I can only take that course through SVN commands. This is a cool
thing about SVN, that it not only knows but records these
distinctions; blurring them at certain parts of the UI is confusing.
Might be justified, but it needs extraordinary justification to
violate the fundamental UI model so thoroughly.
>I think the most common use case of 'svn diff URL1 URL2' is comparing
>trees that are *unrelated* to each other... and therefore this command
>should produce a path-based diff by default.
Color me mystified: if URL1 and URL2 are unrelated, then don't you
get the same output with or without --notice-ancestry?
>A common use-case here is when someone imports two different releases
>of 3rd party software. On the one hand, we have a fancy
>svn_load_dirs.pl script that helps users *force* the two imported
>trees to be related to one another. On the other hand, many people
>don't use that script. And when they run 'svn diff URL1 URL2',
>they're simply asking the question, "what changed between releases?"
Ah ... you're saying "the user foolishly created trees that do not
record their relationship within SVN," right? The trees are
conceptually related, but the user neglected to mention that to SVN
during the import. As a result, SVN naively repeats back to them
"wow, man, you got a whole *bunch* of unrelated stuff, here!"
You think that, in this case, SVN can have the intuition (if not
indeed clairvoyance) to "do what the user meant, not what he said,"
inferring a relationship where none has been attested by the user. I
guess I'd say that the use case "botched the import" is real enough
to deserve some support, but need not be the "common" one that drives
the defaults.
>I've talked to users, I've seen them
>surprised by this... it's not what they expect to see. They expect a
>path-based diff.
No doubt. People are generally surprised when reality does not match
their expectations. In this case, you might do them the greater
service by helping them "take their first step into a larger world"
of versioned directories. Versioned directories is not an "under the
hood" thing for SVN, it's a user-visible feature -- indeed, one of
the chief selling points. Not only does it deserve to be known by
the user, not only does it provide great value for the user, but it's
even wonderful enough to justify the trouble of educating the user.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Ben Collins-Sussman <su...@collab.net>.
Jack Repenning <jr...@collab.net> writes:
> But, if URL1 and URL2 are directories (as in the situation that
> started this topic), then "d/a" has a very explicit meaning, which is
> distinct and distinguishable from "u", and I "would expect" either
> diff or merge to say or do the thing appropriate to whatever really
> happened. In diff-speak, if we're talking about a new version of the
> same node, then that's a "U" (or "G" or "P"); if we mean a different
> node was given the same name, then that's a "D/A". In merge-speak, if
> it's a new version of the same node, then the delta should be applied
> to the version presently in the target (described above); if it's a
> different node, then the target version should be deleted and the
> appropriate version of the new node linked in.
Yes, you've exactly explained the difference between a file/dir that
is merely changed, versus one that has been deleted + re-added.
That's exactly what we're talking about.
> So: I think there is a distinction to be respected here, but it's not
> "diff or merge" but "directory or file." In the file cases, I find
> compelling precedent for a fairly complex behavior, some of which I
> think you describe as "respecting history" and some as "ignoring it."
There's no distinction between file or directory behavior.
If a directory was deleted and then re-added, I would expect 'svn
merge' to replay that exact bit of history: delete the whole tree,
re-add it. If a file was deleted and re-added, I would expect the
same behavior. I don't understand the "complex" behaviors that
differentiate files and dirs... or maybe I do, but I don't follow you
at the moment.
> But again, the compelling distinction is "what are we trying to do,"
> not "what mood is the user in today," nor "how to I flip a bit in
> the code as it lies today."
Let me clarify, using a different route.
We're comparing the behaviors of 'svn diff URL1 URL2' and 'svn merge
URL1 URL2 .' Under the hood, these are both doing the same thing:
asking the server to compare two repository trees. The comparison
engine, svn_repos_dir_delta(), has the ability to create either
history-based tree deltas (noticing whether nodes are related), or the
ability to create path-based deltas (just comparing similar paths,
ignoring historical relatedness.)
Notice -- the working copy library doesn't track history very well.
It doesn't actually care which sort of tree-delta is applied during a
merge, because the *result* will always be the same: that is, the
exact, predicted set of data will be on disk when the merge completes.
Now here's my argument:
Many people seem to think that the 'svn diff' command is most commonly
used as a preview of the 'svn merge' command... and thus that they
should behave exactly the same. I'm saying that based on my chats
with users, this *isn't* the most common use case of 'svn diff URL1
URL2'. (And besides, we have 'svn merge --dry-run' for previews.)
I think the most common use case of 'svn diff URL1 URL2' is comparing
trees that are *unrelated* to each other... and therefore this command
should produce a path-based diff by default.
A common use-case here is when someone imports two different releases
of 3rd party software. On the one hand, we have a fancy
svn_load_dirs.pl script that helps users *force* the two imported
trees to be related to one another. On the other hand, many people
don't use that script. And when they run 'svn diff URL1 URL2',
they're simply asking the question, "what changed between releases?"
If 'svn diff' is "smart" and sensitive to history, the user ends up
seeing the deletion of the entire URL1 tree, followed by the addition
of the entire URL2 tree. I maintain this is Bad, because it does not
answer the user's question. I've talked to users, I've seen them
surprised by this... it's not what they expect to see. They expect a
path-based diff.
On the other hand, when a user runs 'svn merge', it's important to
replay history... because the only output a user sees are little
letter codes. And they expect these codes to show historical actions,
like "D + A", rather than just applying a path-based diff ("U").
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Jack Repenning <jr...@collab.net>.
At 1:26 PM -0500 8/22/03, Ben Collins-Sussman wrote:
>Can you be more specific? What's inconsistent? Why *specifically* is
>the inconsistency confusing?
As I said, the most compelling confusion I have is, "what on earth
does your speculation about my expectations actually suggest?" I'm
not saying you end up with the wrong answer, I'm saying there is no
inference there. There is, however, another basis for more reliably
deriving expectation, because these things "diff" and "merge" have
been going on for ages before SVN was ever thunk.
>Are you arguing that if I run
>
> $ svn diff URL1 URL2
>
> ... and see a true diff on 'foo', that I will surprised and
> confused when I then run
>
> $ svn merge URL1 URL2 .
> D foo
> A foo
>
> ... and see the delete + add, rather than "U foo" ?
In another message, I pointed out SVN's opportunity to handle
directories and files differently. I'm not sure which you mean here;
I suspect this example is getting muddled (at least in my head) by
ignoring this distinction. I think there *is* a reasonable
expectation for SVN to behave differently for the two, and there's no
precedent (say, in CVS) for how SVN should handle directories (since
CVS doesn't), so it's still "least surprising" to allow a variation
here.
So, if URL1 and URL2 are files: then the expected behavior for diff
is dependent upon which diff output format you have chosen; they all
have well-defined expectations for this very common situation; some
"respect" and some "ignore" history. Similarly, for merge, the
behavior is well established: if a line has been changed along only
one path, make the change; if a line has been changed along both
paths, conflict (a uniformly history-respecting behavior).
But, if URL1 and URL2 are directories (as in the situation that
started this topic), then "d/a" has a very explicit meaning, which is
distinct and distinguishable from "u", and I "would expect" either
diff or merge to say or do the thing appropriate to whatever really
happened. In diff-speak, if we're talking about a new version of the
same node, then that's a "U" (or "G" or "P"); if we mean a different
node was given the same name, then that's a "D/A". In merge-speak,
if it's a new version of the same node, then the delta should be
applied to the version presently in the target (described above); if
it's a different node, then the target version should be deleted and
the appropriate version of the new node linked in. (There's a
separate topic we've discussed: is it a merge conflict if one line
has changed a file and another has deleted it. For the purpose of
this discussion, assume whichever answer you like for that question;
the point here is that SVN does know the difference between "u" and
"d/a" for directories, and ought to respect it.)
So: I think there is a distinction to be respected here, but it's not
"diff or merge" but "directory or file." In the file cases, I find
compelling precedent for a fairly complex behavior, some of which I
think you describe as "respecting history" and some as "ignoring it."
The controlling model is not expectation about that, but the
"artifact standard" of preexisting tools and their behavior. In the
directory cases, we find ourselves without precedents (at least,
among the CVS users), and we have something very valuable to provide,
and perhaps even something worth bragging about. But again, the
compelling distinction is "what are we trying to do," not "what mood
is the user in today," nor "how to I flip a bit in the code as it
lies today."
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Here is an example
>
> $ svnadmin create repo
> $ svn mkdir -m "" file://`pwd`/repo/foo
> $ svn import -m "" svn-config file://`pwd`/repo/foo/bar
> $ svn cp -m "" file://`pwd`/repo/foo file://`pwd`/repo/foo2
> $ svn rm -m "" file://`pwd`/repo/foo2/bar
> $ svn import -m "" Makefile file://`pwd`/repo/foo/bar
Oops, that last one should be foo2 not foo
$ svn import -m "" Makefile file://`pwd`/repo/foo2/bar
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Philip Martin <ph...@codematters.co.uk>.
Jack Repenning <jr...@collab.net> writes:
> At 10:33 AM +1000 8/23/03, William Uther wrote:
>> I'm a user who has been on the list a while, and thought about this
>> a bit, and I think I'd rather have diff honour ancestry
Me too.
> I'm still trying to understand what that means. Can you help poor me?
> I think diff has the job of printing things to the screen; what's the
> difference between what's printed, with or without "honorable
> ancestors"?
Here is an example
$ svnadmin create repo
$ svn mkdir -m "" file://`pwd`/repo/foo
$ svn import -m "" svn-config file://`pwd`/repo/foo/bar
$ svn cp -m "" file://`pwd`/repo/foo file://`pwd`/repo/foo2
$ svn rm -m "" file://`pwd`/repo/foo2/bar
$ svn import -m "" Makefile file://`pwd`/repo/foo/bar
Now running
$ svn diff --notice-ancestry file://`pwd`/repo/foo file://`pwd`/repo/foo2
shows foo/bar being deleted and foo2/bar being added, while
$ svn diff file://`pwd`/repo/foo file://`pwd`/repo/foo2
shows a unifed diff between the two files imported as bar.
Some people think the unified diff should be the default because the
files have the same name, others think the add/delete should be the
default because that's what the history records.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Jack Repenning <jr...@collab.net>.
At 10:33 AM +1000 8/23/03, William Uther wrote:
>I'm a user who has been on the list a while, and thought about this
>a bit, and I think I'd rather have diff honour ancestry
I'm still trying to understand what that means. Can you help poor
me? I think diff has the job of printing things to the screen;
what's the difference between what's printed, with or without
"honorable ancestors"?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by William Uther <wi...@cse.unsw.edu.au>.
On Monday, August 25, 2003, at 04:32 AM, Ben Collins-Sussman wrote:
> Jack Repenning <jr...@collab.net> writes:
>
>>> I view diff as a dry-run of merge and if merge is going to delete
>>> and re-add lots of lines, then I want to know that.
>>
>> My questions about diff's honorable ancestors notwithstanding .. what
>> if merge had a "--dry-run" switch, that really actually guaranteedly
>> showed you what merge would do without actually doing anything?
>
> $ svn help merge
> merge: apply the differences between two sources to a working copy
> path.
> [...]
> --dry-run : try operation but make no changes
> [...]
Yes, but this doesn't print diffs...
\me drops back to lurker mode now...
Will :-}
--
Dr William Uther National ICT Australia
Phone: +61 2 9385 6926 School of Computer Science and
Engineering
Email: willu@cse.unsw.edu.au University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Ben Collins-Sussman <su...@collab.net>.
Jack Repenning <jr...@collab.net> writes:
> > I view diff as a dry-run of merge and if merge is going to delete
> > and re-add lots of lines, then I want to know that.
>
> My questions about diff's honorable ancestors notwithstanding .. what
> if merge had a "--dry-run" switch, that really actually guaranteedly
> showed you what merge would do without actually doing anything?
$ svn help merge
merge: apply the differences between two sources to a working copy path.
[...]
--dry-run : try operation but make no changes
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Jack Repenning <jr...@collab.net>.
At 10:33 AM +1000 8/23/03, William Uther wrote:
> I view diff as a dry-run of merge and if merge is going to delete
>and re-add lots of lines, then I want to know that.
My questions about diff's honorable ancestors notwithstanding .. what
if merge had a "--dry-run" switch, that really actually guaranteedly
showed you what merge would do without actually doing anything?
Would that take the pressure off diff to be "just like merge"?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Merging confuses renamed files
Posted by Sander Striker <st...@apache.org>.
[responding late in the game since I'm getting mails up to 3 days old]
> From: William Uther [mailto:willu.mailingLists@cse.unsw.edu.au]
> Sent: Saturday, August 23, 2003 2:34 AM
> I'm a user who has been on the list a while, and thought about this a
> bit, and I think I'd rather have diff honour ancestry -- I view diff as
> a dry-run of merge and if merge is going to delete and re-add lots of
> lines, then I want to know that.
If it honours ancestry you'll only see the changes made between the
new file and the original file, regardless of it being renamed.
I think that's ok though. I too feel that diff should resemble
dry-run of merge.
> That still leaves the problem of what happens when you diff unrelated
> files. Well, if the files are related, then use ancestry, otherwise
> print a "warning: unrelated files" and ignore ancestry. But what I
> really want is a way to edit ancestry easily!
Ook! That's certainly post 1.0.
> If I use diff, and get lots of warnings about unrelated files, then I'd
> like to be able to tell svn, "look, I know the person who added this
> file didn't follow your rules, but just treat these two files as
> related please." (My very vague knowledge of the svn schema suggests
> something about adding a line to a copies table to turn the original
> add into an add with history? I'm not sure how the copy table and node
> id's relate here.)
I'm not so sure how this will work. It possibly means the rewriting of
nodeids in history and that's not something I particularly fancy. We'll
have to see when there are more resources to invest in attacking things
like this.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by William Uther <wi...@cse.unsw.edu.au>.
On Saturday, August 23, 2003, at 04:26 AM, Ben Collins-Sussman wrote:
> Jack Repenning <jr...@collab.net> writes:
>
>> Leaving aside my doubts as to whether this is actually relevant to
>> John's original question, yeah, I think I object. I'm very
>> uncomfortable with the rationale you propose. Not the least of my
>> discomfort is, I can't for the life of me figure out what your "when
>> you do this, you do or don't care" ideas imply about what (you think)
>> I expect to see on screen!
>
> Jack, I'm not making up "what users expect" on a whim. My proposal is
> based on real feedback from users... although understandably, you've
> not been on this list long enough to be aware of this feedback.
I'm a user who has been on the list a while, and thought about this a
bit, and I think I'd rather have diff honour ancestry -- I view diff as
a dry-run of merge and if merge is going to delete and re-add lots of
lines, then I want to know that.
That still leaves the problem of what happens when you diff unrelated
files. Well, if the files are related, then use ancestry, otherwise
print a "warning: unrelated files" and ignore ancestry. But what I
really want is a way to edit ancestry easily!
If I use diff, and get lots of warnings about unrelated files, then I'd
like to be able to tell svn, "look, I know the person who added this
file didn't follow your rules, but just treat these two files as
related please." (My very vague knowledge of the svn schema suggests
something about adding a line to a copies table to turn the original
add into an add with history? I'm not sure how the copy table and node
id's relate here.)
Interestingly, this has come up before:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=35541
later,
Will :-}
--
Dr William Uther National ICT Australia
Phone: +61 2 9385 6926 School of Computer Science and
Engineering
Email: willu@cse.unsw.edu.au University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Ben Collins-Sussman <su...@collab.net>.
Jack Repenning <jr...@collab.net> writes:
> Leaving aside my doubts as to whether this is actually relevant to
> John's original question, yeah, I think I object. I'm very
> uncomfortable with the rationale you propose. Not the least of my
> discomfort is, I can't for the life of me figure out what your "when
> you do this, you do or don't care" ideas imply about what (you think)
> I expect to see on screen!
Jack, I'm not making up "what users expect" on a whim. My proposal is
based on real feedback from users... although understandably, you've
not been on this list long enough to be aware of this feedback. I'll
give evidence below.
Let me summarize the history here:
- In the beginning, 'svn diff' and 'svn merge' both honored ancestry.
- Recently, cmpilato made both command ignore ancestry by default.
- I'm proposing that just 'svn merge' go back to honoring ancestry by default.
* 'svn diff' behavior -- what do users expect?
Not too long ago, 'svn diff URL1 URL2' used to confuse the heck
out of people. Often the two trees would be independent imports
were nearly identical, and the screen output would be a zillion
'-' lines to delete 'foo', followed by a zillion '+' lines to
re-add another file named 'foo' that was ancestrally unrelated.
And this would happen over and over on every changed file. Users
would complain: "what the heck? There's only one-line difference
between these versions of 'foo'. Why doesn't it just *diff* them
like I expect?" And then we'd go off on long explanations about
how the files were unrelated to each other, and how to make them
related in the future, yada yada.
All the confusion vanished when cmpilato (recently) made 'svn
diff' ignore ancestry by default. It now does "what users
expect". No more spurious deletes/adds of what looks like the
same file. It just diffs the two files directly.
* 'svn merge' behavior -- what do users expect?
Granted, this is more based on a personal feeling, rather than
coming from user feedback. When cmpilato made 'svn diff' ignore
ancestry by default, he *also* changed 'svn merge' to do the same,
and I think it was a mistake. As I said in an earlier mail, *I*
don't want to see "U foo" during the merge, when somebody actually
bothered to delete and re-add the file. That's covering up the
intent of the changeset. Merges are all about keeping things
related, and if the old 'foo' and the new 'foo' are unrelated, I'd
like to know! Is there a counter-argument I'm missing?
> I think "least surprise" means "it did this the last time, it should
> do it again this time." It's about repeatability. It also means "if
> I'm seeing some characters on the screen, they should mean the same
> thing here that they did the last time I saw the same characters."
Can you be more specific? What's inconsistent? Why *specifically* is
the inconsistency confusing?
Are you arguing that if I run
$ svn diff URL1 URL2
... and see a true diff on 'foo', that I will surprised and
confused when I then run
$ svn merge URL1 URL2 .
D foo
A foo
... and see the delete + add, rather than "U foo" ?
> It's not about razor distinctions, it's about clarity. In this realm,
> it's also about consistency with established precedents--the zillion
> diff and merge tools we've all used before. No version control system
> is an island....
What precedents? What intuitions are we contradicting here?
My experience is that users running 'svn diff' expect a 'dumb' diff,
and users running 'svn merge' expect a 'smart' merge.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Jack Repenning <jr...@collab.net>.
At 10:48 AM -0500 8/22/03, Ben Collins-Sussman wrote:
>So my proposal is to do the least surprsing thing in each case: 'svn
>diff' should ignore ancestry by default, and 'svn merge' should honor
>ancestry by default. (Of course we'd have switches to allow opposite
>behaviors.)
>
>Any objections to this?
Leaving aside my doubts as to whether this is actually relevant to
John's original question, yeah, I think I object. I'm very
uncomfortable with the rationale you propose. Not the least of my
discomfort is, I can't for the life of me figure out what your "when
you do this, you do or don't care" ideas imply about what (you think)
I expect to see on screen!
In order to reach the solution you call "least surprising," you
engaged in an email discussion, put your heat together with a
coworker (and both he and you are intimately familiar with the
internals), and reversed yourself at least once, and made some
crucial assumptions about what the user "wants" at some indefinite
moment in the future when this all matters. That strikes me as a bit
too much work to demand of the user merely to avoid a surprise.
I think "least surprise" means "it did this the last time, it should
do it again this time." It's about repeatability. It also means "if
I'm seeing some characters on the screen, they should mean the same
thing here that they did the last time I saw the same characters."
It's not about razor distinctions, it's about clarity. In this
realm, it's also about consistency with established precedents--the
zillion diff and merge tools we've all used before. No version
control system is an island....
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> John Goerzen <jg...@complete.org> writes:
>
> > My question is: why? Subversion has enough information to duplicate
> > the upstream changes locally, but doesn't. It appears to be behaving
> > as if --ignore-ancestry was given to merge, but it wasn't.
> >
> > Can anybody shed some light on this?
>
> Um ... Ben and I, kinda, made --ignore-ancestry the default. It's now
> --notice-ancestry. But the other day, Ben started having second
> thoughts, and now I am, too. Should this be reverted?
Here's my thoughts, which I think cmpilato now agrees with:
* when you run 'svn diff', you don't care *how* the change came
into being, you just want to see the net result to your working
copy . Seeing a "delete foo; add foo" is completely annoying
and useless -- especially in unified diff output.
* when you 'svn merge' the exact same change to your working copy,
you *want* to see the intent of the change. It's important to
see a "D foo, A foo" displayed -- don't cover up this fact by
displaying "U foo". It's a piece of useful information.
So my proposal is to do the least surprsing thing in each case: 'svn
diff' should ignore ancestry by default, and 'svn merge' should honor
ancestry by default. (Of course we'd have switches to allow opposite
behaviors.)
Any objections to this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by Ben Collins-Sussman <su...@collab.net>.
"Sander Striker" <st...@apache.org> writes:
> We should have at least two options: --ignore-ancestry and --notice-ancestry.
I absolutely agree. I've only been arguing about *default* behaviors
-- "what will surprise users the least?" But diff and merge should be
able to run in *either* mode.
* I think 'svn merge' should honor ancestry by default, but I can
see a use-case where someone wants merge to run faster. If a
merge involves deleting and re-adding a large tree, it can be much
faster to just apply path-based changes.
* I think 'svn diff' should ignore ancestry by default, because it's
so often used to compare unrelated trees. But I absolutely
understand the the other use case: 'svn diff --notice-ancestry'
can be used as a true preview of a merge, with much more detail
than you get from 'svn merge --dry-run'.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Merging confuses renamed files
Posted by Sander Striker <st...@apache.org>.
> From: cmpilato@localhost.localdomain
> [mailto:cmpilato@localhost.localdomain]On Behalf Of cmpilato@collab.net
> Sent: Friday, August 22, 2003 5:42 PM
> John Goerzen <jg...@complete.org> writes:
>
> > My question is: why? Subversion has enough information to duplicate
> > the upstream changes locally, but doesn't. It appears to be behaving
> > as if --ignore-ancestry was given to merge, but it wasn't.
> >
> > Can anybody shed some light on this?
>
> Um ... Ben and I, kinda, made --ignore-ancestry the default. It's now
> --notice-ancestry. But the other day, Ben started having second
> thoughts, and now I am, too. Should this be reverted?
Yes.
We should have at least two options: --ignore-ancestry and --notice-ancestry.
And it would be nice to have this option in the config file too, so
you can set your personal default to one and use the rarer case (for you)
via a cmdline override.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging confuses renamed files
Posted by cm...@collab.net.
John Goerzen <jg...@complete.org> writes:
> My question is: why? Subversion has enough information to duplicate
> the upstream changes locally, but doesn't. It appears to be behaving
> as if --ignore-ancestry was given to merge, but it wasn't.
>
> Can anybody shed some light on this?
Um ... Ben and I, kinda, made --ignore-ancestry the default. It's now
--notice-ancestry. But the other day, Ben started having second
thoughts, and now I am, too. Should this be reverted?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org