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

On Wed, Jun 27, 2012 at 7:48 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----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 just confirmed with trunk: same behavior.

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

Can you elaborate a bit, why this can't be calculated without
consulting the repository?

Can the server send the last changed revision over to the client after
commit, to be used in the post commit processing? Or does it do that
already?

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

In this case I think 'subdir' is already touched by the post commit
processing, because its working revision is correct. If its working
revision was still left to '2', there wouldn't be any problem, because
a subsequent 'update' would bring it up to date (both working and last
changed revision can then be brought up to 3). In this case, the
working revision is already 3, but last changed rev is left at 2,
which is simply incorrect. A subsequent update cannot repair this.

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

Hm, I just hope that the last changed rev is always correct relative
to the working revision. If both aren't bumped, there is no problem
(mixed rev working copy etc ... they can always be bumped later on an
update or something). But the LCR in any working copy should (I think)
always match the LCR of URL_at_REV (where REV is the working revision
from the working copy).

-- 
Johan