You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Augie Fackler <du...@gmail.com> on 2008/03/23 21:50:59 UTC
Odd "diff" behavior
(http://blue.bikeshed.com/)
I was setting up ReviewBoard the other day, and I noticed that a diff
of a merge operation doesn't include files added by the merge. As an
example ($PWD is a branches/1.5.x working copy):
$ svn merge -r29788:29789 http://svn.collab.net/repos/svn/trunk
--- Merging r29789 into '.':
A notes/wc-2.0-design
$ svn st [03/23/08 4:47PM]
M .
A + notes/wc-2.0-design
$ svn diff
Property changes on: .
___________________________________________________________________
Modified: svn:mergeinfo
Merged /trunk:r29789
Which seems wrong to me. If I did a normal add of the file, it would
show up in the diff. Is my expectation of seeing the added file in the
diff wrong? The big thing to me is that there's no evidence at all
from the diff output that there was an added file.
Peace,
Augie
Re: Odd "diff" behavior
Posted by Augie Fackler <du...@gmail.com>.
On Mar 24, 2008, at 11:17 AM, Ben Collins-Sussman wrote:
> This is history repeating itself: we had long debates about this
> problem years ago.
>
> The fact is, sometimes you want to see the *entire* copied file, and
> sometimes you want to see just the way in which you *changed* the
> copied file. They're both legitimate use-cases, and we went back and
> forth on what should be the default behavior.
>
> My recollection, though, is that we had decided to add a switch to
> 'svn diff' so that you could trigger either behavior. Seems like we
> never did that, though?
That does seem to be the case. For now, I'll just find a way to change
the code review tool to handle the added-with-history case and produce
that part of the diff without svn's help. Long-term, I might try and
add an option to the diff command.
Peace,
Augie
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
Re: Odd "diff" behavior
Posted by Ben Collins-Sussman <su...@red-bean.com>.
This is history repeating itself: we had long debates about this
problem years ago.
The fact is, sometimes you want to see the *entire* copied file, and
sometimes you want to see just the way in which you *changed* the
copied file. They're both legitimate use-cases, and we went back and
forth on what should be the default behavior.
My recollection, though, is that we had decided to add a switch to
'svn diff' so that you could trigger either behavior. Seems like we
never did that, though?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Odd "diff" behavior
Posted by "C. Michael Pilato" <cm...@collab.net>.
Stefan Sperling wrote:
> Augie and I were wondering why we don't compare files marked as
> added-with-history against an empty file instead of the copy source?
> Cause in essence, this would more accurately reflect the changes
> that are about to be committed.
>
> Was there a conscious decision behind this or did it simply evolve
> from the facts you stated?
There was a conscious decision for merged adds to be added with history.
There was a conscious decision for add-with-history files to only display
diffs against the previous history location. Those two things together form
the behavior we have today.
However, I'm not sure whether there was ever a conscious decision that
involved both of these situations at once, if you know what I mean.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Odd "diff" behavior
Posted by Augie Fackler <du...@gmail.com>.
On Mar 24, 2008, at 6:11 AM, Stefan Sperling wrote:
> On Mon, Mar 24, 2008 at 11:19:51AM +0100, Karl Heinz Marbaise wrote:
>> Hi Stefan,
>>> stsp@ted [wc] $ svn cp a b
>>> A b
>>> stsp@ted [wc] $ svn diff
>>> stsp@ted [wc] $ svn st
>>> A + b
>>> stsp@ted [wc] $ echo c > c
>>> stsp@ted [wc] $ svn add c
>>> A c
>>
>> Have you ever tried this:
>>
>> find -type f | xargs ls -al
>> than you see things like this:
>> .... .svn/entries
>> .svn/format
>> .svn/text-base/a
>> .svn/text-base/b
>> ./a
>> ./b
>> ./c
>>
>>> Why isn't the diff for b shown?
>>> Was this a deliberate design decision?
>>>
>> And this is reason why svn diff will only print information for "c",
>> cause it's building the difference between the pristine copy (.svn)
>> and
>> your working area. You see the missing "c" under .svn/text-base ?
>
> OK, thanks for pointing that out.
>
> So that is the way it's currently being done.
>
> Augie and I were wondering why we don't compare files marked as
> added-with-history against an empty file instead of the copy source?
> Cause in essence, this would more accurately reflect the changes
> that are about to be committed.
>
> Was there a conscious decision behind this or did it simply evolve
> from the facts you stated?
Right on - it makes code review more difficult (not impossible,
obviously) when diff doesn't actually show you what will be committed.
For what it's worth, Mercurial does behave as I expected. That's the
only other VCS I have handy and already running. I see why it happens,
I'm just curious if the UI is intentional or if I should try to fix
this (realizing I'll need to insert workarounds for existing versions
in the review tool I want to use).
Peace,
Augie
Re: Odd "diff" behavior
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 24, 2008 at 11:19:51AM +0100, Karl Heinz Marbaise wrote:
> Hi Stefan,
> > stsp@ted [wc] $ svn cp a b
> > A b
> > stsp@ted [wc] $ svn diff
> > stsp@ted [wc] $ svn st
> > A + b
> > stsp@ted [wc] $ echo c > c
> > stsp@ted [wc] $ svn add c
> > A c
>
> Have you ever tried this:
>
> find -type f | xargs ls -al
> than you see things like this:
> .... .svn/entries
> .svn/format
> .svn/text-base/a
> .svn/text-base/b
> ./a
> ./b
> ./c
>
> > Why isn't the diff for b shown?
> > Was this a deliberate design decision?
> >
> And this is reason why svn diff will only print information for "c",
> cause it's building the difference between the pristine copy (.svn) and
> your working area. You see the missing "c" under .svn/text-base ?
OK, thanks for pointing that out.
So that is the way it's currently being done.
Augie and I were wondering why we don't compare files marked as
added-with-history against an empty file instead of the copy source?
Cause in essence, this would more accurately reflect the changes
that are about to be committed.
Was there a conscious decision behind this or did it simply evolve
from the facts you stated?
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: Odd "diff" behavior
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Stefan,
> stsp@ted [wc] $ svn cp a b
> A b
> stsp@ted [wc] $ svn diff
> stsp@ted [wc] $ svn st
> A + b
> stsp@ted [wc] $ echo c > c
> stsp@ted [wc] $ svn add c
> A c
Have you ever tried this:
find -type f | xargs ls -al
than you see things like this:
.... .svn/entries
.svn/format
.svn/text-base/a
.svn/text-base/b
./a
./b
./c
> Why isn't the diff for b shown?
> Was this a deliberate design decision?
>
And this is reason why svn diff will only print information for "c",
cause it's building the difference between the pristine copy (.svn) and
your working area. You see the missing "c" under .svn/text-base ?
So in the case of a copied file (b) it won't print out anything, cause
there is no difference between pristine copy and the working area.
On the other hand what kind of difference should it print out, cause it
copied from an existing file...so in consequence it should calculate the
difference between the target of the copy operation and the source but
this should print nothing at all...cause there is no difference between
the source and the destination...
Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Odd "diff" behavior
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Mar 23, 2008 at 06:53:21PM -0500, Augie Fackler wrote:
> My personal interpretation of the diff command was
> always "what is different as compared to the last-updated-rev of the wc?"
> which isn't what it actually does - I'm raising a UI question, not actually
> saying it's wrong. Does anyone else see the expected behavior I do, or am I
> the odd case out?
I've seen this also before and found it quite irritating.
If you are used to how "diff/patch" works, then "svn diff"
is acting weird in this particular case.
To illustrate again what we are talking about:
stsp@ted [wc] $ svn cp a b
A b
stsp@ted [wc] $ svn diff
stsp@ted [wc] $ svn st
A + b
stsp@ted [wc] $ echo c > c
stsp@ted [wc] $ svn add c
A c
stsp@ted [wc] $ svn diff
Index: c
===================================================================
--- c (revision 0)
+++ c (revision 0)
@@ -0,0 +1 @@
+c
stsp@ted [wc] $
stsp@ted [wc] $ svn st
A + b
A c
stsp@ted [wc] $
Why isn't the diff for b shown?
Was this a deliberate design decision?
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: Odd "diff" behavior
Posted by Augie Fackler <du...@gmail.com>.
On Mar 23, 2008, at 6:08 PM, Karl Heinz Marbaise wrote:
> Hi,
>
>> $ svn merge -r29788:29789 http://svn.collab.net/repos/svn/trunk
>> --- Merging r29789 into '.':
>> A notes/wc-2.0-design
>> $ svn st [03/23/08 4:47PM]
>> M .
>> A + notes/wc-2.0-design
>> $ svn diff
>>
>> Property changes on: .
>> ___________________________________________________________________
>> Modified: svn:mergeinfo
>> Merged /trunk:r29789
>
>
>> If I did a normal add of the file,
> This is exactly what you didn't have done.
> The file has been added on the branch (or in this case on the trunk).
> This is indicated by the "+" sign after "A" and merged it into the
> working copy.
I understand that - my point is the behavior is different for normal
adds vs add-with-history.
>
>
>> it would show up in the diff.
> I would say no, cause the file in this particular case has an ancestry
> (comming from the trunk; merged or in other words copied) in this
> particular case.
>
> You will get the same result if you only copy a file in the WC (svn cp
> file3.txt fileC.txt; Diff will print out nothing,
> but svn status will print out:
> A + fileC.txt
>
> So this means there is no difference between the copied file and the
> original. And a merged file is (not really) more than a copied file.
See below.
>
>
>> Is my expectation of seeing the added file in the
>> diff wrong?
> My first thought was i expected it too...but i tested it with SVN
> 1.4.2
> and get exactly the same result....and then i thought a little bit
> about
> and came to the result i would say yes you are wrong...
I know the results are the same in 1.4.x (and presumably earlier), but
the thing that frustrates me about this is that the diff gives
absolutely no indication there is anything changed given a file added
with history, which seems wrong to me. My personal interpretation of
the diff command was always "what is different as compared to the last-
updated-rev of the wc?" which isn't what it actually does - I'm
raising a UI question, not actually saying it's wrong. Does anyone
else see the expected behavior I do, or am I the odd case out? It
doesn't feel "right" to be doing the diff of a copied file against the
copy source, but instead against the path.
Thanks,
Augie
>
>
> Kind regards
> Karl Heinz Marbaise
> --
> SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
> Hauptstrasse 177 USt.IdNr: DE191347579
> 52146 Würselen http://www.soebes.de
Re: Odd "diff" behavior
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
> $ svn merge -r29788:29789 http://svn.collab.net/repos/svn/trunk
> --- Merging r29789 into '.':
> A notes/wc-2.0-design
> $ svn st [03/23/08 4:47PM]
> M .
> A + notes/wc-2.0-design
> $ svn diff
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
> Merged /trunk:r29789
> If I did a normal add of the file,
This is exactly what you didn't have done.
The file has been added on the branch (or in this case on the trunk).
This is indicated by the "+" sign after "A" and merged it into the
working copy.
> it would show up in the diff.
I would say no, cause the file in this particular case has an ancestry
(comming from the trunk; merged or in other words copied) in this
particular case.
You will get the same result if you only copy a file in the WC (svn cp
file3.txt fileC.txt; Diff will print out nothing,
but svn status will print out:
A + fileC.txt
So this means there is no difference between the copied file and the
original. And a merged file is (not really) more than a copied file.
> Is my expectation of seeing the added file in the
> diff wrong?
My first thought was i expected it too...but i tested it with SVN 1.4.2
and get exactly the same result....and then i thought a little bit about
and came to the result i would say yes you are wrong...
Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org