[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: incorrect Last Changed Rev after upgrade from 1.6.17 to 1.7.5

From: Vincent Lefevre <vincent-svn_at_vinc17.net>
Date: Tue, 19 Jun 2012 12:37:06 +0200

On 2012-06-19 11:53:37 +0200, Stefan Sperling wrote:
> 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.

Well, not all copy events should be affected. For instance, if a file
is moved from a directory to another one, this should be shown in the
log. Here what is copied is not the file itself, but the directory
above it.

> I would argue this is, if at all, a cosmetic problem in 'svn log' output
> that can be worked around with a filtering wrapper.

I'm not complaining much on the output except that it is not consistent
with the last changed rev when the copy was done. The question is: Is
this regarded as a bug? If it is not, this should be documented.

> 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?

A directory also has a notion of last changed revision. The rule
could be: If when some revision N was committed, it was the last
changed rev of the object, then it should be shown in the log.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Received on 2012-06-19 12:37:42 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.