On Tue, Jun 19, 2012 at 09:46:20AM +0200, Vincent Lefevre wrote:
> On 2012-06-19 01:29:18 -0400, Greg Stein wrote:
> > In 1.6, we erroneously used the containing directory's revision for the
> > file in certain cases. 1.7 is correct: the file is not changed until r4.
> > Maybe the directory has, but that is independent of the file.
>
> But in this case, is it normal that r3 is still in the log of the
> file? For instance, even though r3 is not a changed rev of the file,
> "svn log -v file" gives:
>
> ------------------------------------------------------------------------
> r4 | vinc17 | 2012-06-19 09:36:50 +0200 (Tue, 19 Jun 2012) | 1 line
> Changed paths:
> D /dir2/file
> A /file (from /dir2/file:3)
>
> mv dir2/file .
> ------------------------------------------------------------------------
> r3 | vinc17 | 2012-06-19 09:36:47 +0200 (Tue, 19 Jun 2012) | 1 line
> Changed paths:
> D /dir1
> A /dir2 (from /dir1:2)
>
> mv dir1 dir2
> ------------------------------------------------------------------------
> r2 | vinc17 | 2012-06-19 09:36:44 +0200 (Tue, 19 Jun 2012) | 1 line
> Changed paths:
> A /dir1/file
>
> add dir1/file
> ------------------------------------------------------------------------
>
> IMHO, this can be useful information in the log history, but the
> difference between what is regarded as a "changed rev" of a file
> and the file history that appears in the log doesn't seem to be
> documented.
'svn log' shows both simple copy events and content changes and there
is no way to turn off display of pure copy events.
I would argue this is, if at all, a cosmetic problem in 'svn log' output
that can be worked around with a filtering wrapper.
Say there was an option to 'svn log' that caused only commits which changed
file content to be shown. What should this option if 'svn log' is invoked
on a directory, instead of a file? Ignore the option, or complain, or
something else?
Received on 2012-06-19 11:54:25 CEST