RE: svn diff: output stops after first couple hunks?

["Cooke, Mark" <ma...@siemens.com>]

> -----Original Message-----
> From: Laird Nelson [mailto:ljnelson@gmail.com] 
> Sent: 30 November 2010 21:18
> To: users@subversion.apache.org
> Subject: svn diff: output stops after first couple hunks?
> 
> Hello, and thanks, first of all, for a great version control system.
> 
> I am seeing a very odd behavior that I hope I can chalk up to 
> pilot error.
> 
> One of my developers on Windows 7, running the 
> CollabNet-supported Subversion 1.6.13 binaries, does this command:
> 
> svn diff pom.xml
> 
> ...in a directory with a pom.xml file that has some local 
> changes.  She knows and I know that the upstream Subversion 
> repository, being hosted by Subversion 1.6.2 on a Windows XP 
> box as part of an Apache installation, contains a newer 
> version of this file.

...it sounds like you are expecting `diff` to check against the latest
version in the repository.  This is not what happens, at least using the
command as you provided above.  Most operations within a working copy
use the latest known pristene copy as the reference (i.e. the copy
stored from the _last_ update of _this_ wc in your .svn subdirectories).
Does that exaplin the differences you are seeing?

If so, the solution is to update your wc first (this will not kill any
of your local changes) and run the diff again.  If not, sorry for the
noise.

~ mark c

> svn diff correctly outputs what looks like the first couple 
> hunks.  We both see what we're expecting to see.  Then 
> mysteriously on her machine only, that is all that diff 
> reports.  When I take her locally modified file, and place it 
> in my up-to-date workspace, and run svn diff on it--trying as 
> best as I am able to replicate her environment--I see those 
> same hunks, but then I see MORE hunks.
> 
> I am on a Mac, running Subversion 1.6.5 which came with the machine.
> 
> Are there known diff issues like this?  If it is simply an 
> output problem, then that's one thing, but since diffs are at 
> the core of Subversion's logic I want to make sure we flesh 
> this out if indeed there's a problem.
> 
> I've attempted on her machine to run svn diff -x -w pom.xml 
> with the same results.
> 
> Are there further command line options or steps I should have 
> taken that I'm unaware of?
> 
> Thanks,
> Laird
> 
> 

Re: svn diff: output stops after first couple hunks?

[Daniel Shahaf <d....@daniel.shahaf.name>]

> > I suppose then if I really wanted to do the diff properly 
> > (read: against the copy in the repo) I would do:
> > 
> >   svn diff pom.xml http://path.to/my/svnrepo/myproject/trunk/pom.xml
> > 

svn diff -r HEAD pom.xml

> By the way, do you know the online subversion book
> (http://svnbook.red-bean.com/)?

RE: svn diff: output stops after first couple hunks?

["Cooke, Mark" <ma...@siemens.com>]

> -----Original Message-----
> From: Laird Nelson [mailto:ljnelson@gmail.com] 
> Sent: 01 December 2010 13:01
> To: Cooke, Mark; users@subversion.apache.org
> Subject: Re: svn diff: output stops after first couple hunks?
> 
> > On Wed, Dec 1, 2010 at 3:32 AM, Cooke, Mark 
> > <ma...@siemens.com> wrote:
> > 
> > 
> > ...it sounds like you are expecting `diff` to check against the
latest
> > version in the repository.  This is not what happens, at least using
> > the command as you provided above.
> > 
> 
> You know, I have read words to that effect before, but 
> haven't ever really properly thought about the ramifications.
> 
> 
> > Most operations within a working copy use the latest known pristene
> > copy as the reference (i.e. the copy stored from the _last_ update
of
> > _this_ wc in your .svn subdirectories).
> > 
> > Does that explain the differences you are seeing?
> > 
> 
> I believe it does.  So, to be very clear, she is computing 
> differences between her working copy, and the version that 
> was the result of the last svn update, whenever that happened 
> to have occurred?
> 
Exactly.  Subversion minimises the network traffic by storing the latest
known 'master' locally.  When you do a commit, only the diffs are sent
across the network, hence one reason why a commit will fail if your WC
is not updated...

> I suppose then if I really wanted to do the diff properly 
> (read: against the copy in the repo) I would do:
> 
>   svn diff pom.xml http://path.to/my/svnrepo/myproject/trunk/pom.xml
> 
> ...that is, diff the working pom.xml against the copy stored 
> in the repository?  (I don't have the command or the manual 
> up right now, so I may have left off an argument or two, but 
> hopefully you get the idea.)
> 
While you can do that, most people would simply update the working copy
and then do the diff locally.  You will not be able to commit until you
have updated anyway.

An update will bring in any changes that others have made but these
generally merge silently with your changes and any conflicts will be
flagged for resolution.  This is one reason for updating regularly,
these merges seem to work best when taken in smaller increments!

By the way, do you know the online subversion book
(http://svnbook.red-bean.com/)?  It is very good and the first two
chapters should be compulsory reading for all users.  The `svn diff`
reference is here:
http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.diff.html

~ mark c