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

On Thu, Jun 28, 2012 at 11:58 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
>> Sent: donderdag 28 juni 2012 00:43
>> To: Bert Huijben
>> Cc: Subversion Development
>> Subject: 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).
>
> The working revision is bumped on every update for every node not explictly
> updated by the update editor as part of the update finalization. The last
> changed information is only updated by the update processing and by the post
> commit processing. As the commit processing only applies to nodes explicitly
> touched by a commit and then by url instead of by local path it is very hard
> to process nodes in a generic way like you suggest.
> (The last changed values are always determined by the repository, never the
> client for several reasons)

I still don't understand. Are you suggesting that subdir is not
processed by the post-commit logic?

In my example there is no update after committing revision 3. Still,
subdir (which is not the op root, and not an explicit target of the
commit) has its working revision bumped. Doesn't that mean that subdir
is processed by the post-commit handling? How else could it have
gotten working revision 3?

And if that's the case, how come the post-commit logic can't also give
it the correct last changed revision? Right now, the post-commit
processing put incorrect information into subdir's metadata. Does the
server not communicate that information correctly (like it does for
setting the last changed rev of 'dir2' and 'test.txt')? Or is it too
difficult to map the information coming from the server onto the local
relpath of subdir or something like that?

-- 
Johan