[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: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 27 Jun 2012 19:48:41 +0200

> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: woensdag 27 juni 2012 16:33
> To: Subversion Development
> Subject: Incorrect LastChangedRev in working copy after committing
> directory move + modified file in subdir
>
> I noticed this while investigating (other) problems with incorrect
> LastChangedRev's (subtle form of working copy corruption):
>
> [[[
> C:\Temp\svntest>svnadmin create testrepos
>
> C:\Temp\svntest>set REPOS=file:///C:/Temp/svntest/testrepos
>
> C:\Temp\svntest>svn mkdir --parents -mm %REPOS%/dir/subdir
>
> Committed revision 1.
>
> C:\Temp\svntest>svn co %REPOS% wc
> A wc\dir
> A wc\dir\subdir
> Checked out revision 1.
>
> C:\Temp\svntest>echo blah > wc\dir\subdir\test.txt
>
> C:\Temp\svntest>svn add wc\dir\subdir\test.txt
> A wc\dir\subdir\test.txt
>
> C:\Temp\svntest>svn commit -mm wc
> Adding wc\dir\subdir\test.txt
> Transmitting file data .
> Committed revision 2.
>
> C:\Temp\svntest>svn up wc
> Updating 'wc':
> At revision 2.
>
> C:\Temp\svntest>svn mv wc\dir wc\dir2
> A wc\dir2
> D wc\dir
> D wc\dir\subdir
> D wc\dir\subdir\test.txt
>
> C:\Temp\svntest>echo blahblah >> wc\dir2\subdir\test.txt
>
> C:\Temp\svntest>svn commit -mm wc
> Deleting wc\dir
> Adding wc\dir2
> Sending wc\dir2\subdir\test.txt
> Transmitting file data .
> Committed revision 3.
>
> C:\Temp\svntest>svn info wc\dir2\subdir
> Path: wc\dir2\subdir
> Working Copy Root Path: C:\Temp\svntest\wc
> URL: file:///C:/Temp/svntest/testrepos/dir2/subdir
> Repository Root: file:///C:/Temp/svntest/testrepos
> Repository UUID: e4b72795-63eb-4b45-afcc-ee0353e630af
> Revision: 3
> Node Kind: directory
> Schedule: normal
> Last Changed Author: jcorve0
> Last Changed Rev: 2
> Last Changed Date: 2012-06-27 16:21:39 +0200 (wo, 27 jun 2012)
>
>
> C:\Temp\svntest>svn info %REPOS%/dir2/subdir
> Path: subdir
> URL: file:///C:/Temp/svntest/testrepos/dir2/subdir
> Repository Root: file:///C:/Temp/svntest/testrepos
> Repository UUID: e4b72795-63eb-4b45-afcc-ee0353e630af
> Revision: 3
> Node Kind: directory
> Last Changed Author: jcorve0
> Last Changed Rev: 3
> Last Changed Date: 2012-06-27 16:23:08 +0200 (wo, 27 jun 2012)
> ]]]
>
> As you can see, the LastChangedRev of subdir is 2 in the working copy,
> but 3 in the repository (with the same working revision). If you
> create a new checkout of this repository, subdir's LastChangedRev will
> be 3, which is correct. So the wrong LastChangedRev is only there in
> the working copy where this commit originated.
>
> - LastChangedRev of 'dir' and test.txt are still correct (3 in this
> case), it's only 'subdir' that's wrong.
>
> - If the file mod of dir/subdir/test.txt isn't committed together with
> the move of dir->dir2, then there is also no problem: in that case,
> subdir and test.txt will have LCR 2 both in the working copy and in
> the repository (so it's not increased, but that's consistent with
> what's in the repository).

I think this specific case is documented in the commit logic. In the generic
case we can't calculate the last changed revision for directories without
more knowledge from the repository. In 1.6 we didn't even set the last
changed revision for files correctly, but we got those cases fixed by the
wc-ng rewrite. (So this at least fixed keyword expansions)

If the directory itself is not committed then the post commit processing
doesn't update the directory at all and updating it anyway is very hard and
maybe even impossible to do correctly in cases like switched nodes.

My guess is that handling commit via editor-v2 will make this an even harder
problem.

        Bert

>
> --
> Johan
Received on 2012-06-27 19:49:30 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.