> -----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)
Yes it is very easy in the common way where you just recursively commit the
working copy root and everything below, in a single revision working copy
without switched paths. But in general we don't have easy working copies
this easy.
Creating separate code paths for the easy and hard cases makes it even
harder to test this code than it is today. Since 1.6 things certainly
improved as I think the last revision for leaves in the working copy (files,
symlinks, etc.) is ok now, but fixing all the corner cases around parent
directories that are or aren't op roots is not something I could even
calculate how much time it would cost.
Bert
Received on 2012-06-28 11:59:17 CEST