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

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

From: Vincent Lefevre <vincent-svn_at_vinc17.net>
Date: Wed, 4 Jul 2012 15:12:38 +0200

On 2012-07-04 14:26:07 +0200, Johan Corveleyn wrote:
> We now have two clearly separate discussions:
>
> - Inconsistencies in LCR between originating WC and repository. That's
> my main interest right now. I think those are clearly bugs (1.6 had
> one, and now 1.7 has another one it seems).
>
> - Whether or not LCR should be updated if a parent directory gets
> moved/renamed. That's more a discussion of specification, what's the
> desired behavior, ... That's a bit out of my personal scope right now,
> but maybe others will participate further in this discussion.

But how the inconsistencies should be fixed depends on the
specification. Specification should come first.

> You mentioned one concrete use-case which breaks down because of
> this: being able to identify a file with URL_at_LCR (I'm not sure if
> this is (or ever was) an intended use-case). Is there other behavior
> that depends on this?

Well, I don't see the point of the URL if the goal is not to
identify the file. And since files can be removed and added,
a peg revision is necessary.

But perhaps the URL could be changed to a URL with a peg revision,
which can be different from LCR.

> Now that I think about it: the current behavior of "LCR not bumped by
> parent move/copy" is there at least since 1.5.

Note that ViewVC behaves differently. See:

  https://gforge.inria.fr/scm/viewvc.php/tags/3.1.1/?root=mpfr

All the Rev's are the same. This is different to what one obtains with
"svn ls -v". The svn version on the server is 1.6.12 (r955767).

> We have a 1.5 repository, and I'm pretty used to the fact that, when
> I look at a branch or tag with a repository browser, that I see the
> LastChangedRev and LastChangeAuthor and Date as being the last "real
> modification" of that file (not the revision which copied the file
> to the branch/tag). I kinda like that behavior...

I think that both kinds of information can be interesting. It is
interesting to see that files under a tag have not been modified
since the tag. But there could be a boolean saying whether the
file had its URL changed since the "real" file change.

-- 
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-07-04 15:13:10 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.