On Sunday, August 15, 2010 12:58:46 pm Stefan Sperling wrote:
> On Sat, Aug 14, 2010 at 11:47:52AM -0700, Alexey Neyman wrote:
> > On Saturday, August 14, 2010 04:31:44 am Stefan Sperling wrote:
> > > > Judging from the commit message, this option should mimic 'git log
> > > > -p' behavior, but git does not dump the whole diff by default when
> > > > -p is specified. It only diffs the requested path and produces a
> > > > full diff only if --full-diff option is also passed.
> > >
> > > There is no need for a --full-diff option.
> > > If you have a commit with two paths, A and B, and you run svn log
> > > --diff A, you will only see a diff for A. So you can limit the scope
> > > of the diff shown by limiting the log operation to just the paths you
> > > are interested in.
> >
> > I know that 'svn log' can take multiple paths. But still, there is a use
> > case for --full-diff:
> >
> > a) One does not know the list of changed paths beforehand. Therefore, one
> > first needs to run 'svn log -v' to find what paths were changed and then
> > run 'svn log --diff' with those paths. This may be quite inconvenient if
> > the paths are scattered over the repository.
> >
> > b) Suppose A is the on which one wants log with diffs; B and C are paths
> > that were changed alongside A:
> >
> > rev X1: A B
> > rev X2: B
> > rev X3: A C
> > rev X4: C
> >
> > Even if full list of paths is supplied, 'svn log --diff A B C' would show
> > revisions X1, X2, X3, X4, while 'svn log --diff --full-diff A' would have
> > shown only revisions X1 and X3 (but with corresponding changes
> > to paths B and C)
>
> Hmmm. You could also list the revisions you want explicitly, but that
> would be awkward to use in complicated cases so I see your point.
> Would you like to try to write and submit a patch that implements this
> option?
I'll try, but first I'd like to see if diff can be made to treat a missing
file as empty. Without it, log --diff would not be usable for me: in our
repository, most of the files originated as a part of some large import. So,
running 'svn log --diff' currently produces the output, 99% of which is not
relevant to the file being logged :(
> > > It may be possible to show the diff anyway treating one of the sides as
> > > empty as you suggest, and thus showing a diff with only adds/deletes.
> > > I agree that this would make sense.
> > >
> > > But making such a change may require substantial work within the
> > > Subversion libraries, so it takes more time than the quick band-aid
> > > fix which I applied to log-cmd.c to make it produce at least some sort
> > > of meaningful output. Sometimes circumstances force people to take
> > > short cuts...
> >
> > Thing is, current approach does not work at all if the parent directory
> > was also added in the same revision as the path being logged. Try this:
> >
> > [[[
> > #! /bin/bash
> > rm -rf tst-repo tst-wc
> > svnadmin create tst-repo
> > svn mkdir -m commit_1 "file://`pwd`/tst-repo/a"
> > svn co "file://`pwd`/tst-repo/a" tst-wc
> > svn mkdir tst-wc/b
> > echo 3 > tst-wc/b/3
> > echo 4 > tst-wc/b/4
> > svn add tst-wc/b/[34]
> > svn ci -m commit_2 tst-wc
> > svn log --diff tst-wc/b/3
> > ]]]
> >
> > 'svn log' at the end of this script hangs indefinitely.
>
> That was a silly bug I fixed yesterday. Please update your working copy,
> rebuild, and check. Your script runs fine for me with current trunk.
Thanks!
> > > It should show a diff which shows things as added. We need the output
> > > to be suitable for use with svn patch. A special message that only
> > > humans will understand isn't useful. Showing a diff with too broad a
> > > scope is much better than showing no diff at all.
> >
> > Given that the changes are in the last-revision-first order, this patch
> > would only be applicable in the reverse direction (if it contains more
> > than one revision).
>
> The last-revision-first order only affects the order in which revisions
> are listed. svn log --diff always shows diffs from revision N-1 to revision
> N, so the revision range of the log operation should not matter.
Oops, I didn't notice that revisions in 'svn log' output can sorted ascending
or descending, depending on whether the revision range is M:N or N:M. With
that in mind, I see how the output of 'svn log --diff' could be passed to the
patch.
However, I still think that 'svn diff' is more convenient as an input to 'svn
patch'. I think that 'svn log --diff' is most useful for human review - it
allows to see both log message and changes at the same time.
Regards,
Alexey.
Received on 2010-08-15 23:37:55 CEST