You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Vincent Lefevre <vi...@vinc17.net> on 2012/07/03 12:56:52 UTC
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
On 2012-06-27 16:33:23 +0200, Johan Corveleyn wrote:
> I noticed this while investigating (other) problems with incorrect
> LastChangedRev's (subtle form of working copy corruption):
It seems to be the same thing I had reported here:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201206.mbox/%3C20120619010211.GE5263%40xvii.vinc17.org%3E
and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678075
--
Vincent Lefèvre <vi...@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)
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Jul 3, 2012 at 11:31 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Tue, Jul 3, 2012 at 2:09 PM, Vincent Lefevre <vi...@vinc17.net> wrote:
>> On 2012-07-03 13:21:35 +0200, Johan Corveleyn wrote:
>>> I just tested my scenario with 1.6: it doesn't have the same issue
>>> (subdir has LastChangedRev 3 in both the working copy and the
>>> repository). So this is a regression in 1.7.
>>
>> The reason why "subdir" has LastChangedRev 3 may be because its parent
>> directory "dir" was renamed to "dir2": with Subversion 1.6, when a
>> directory was copied, all its descendents had their LastChangedRev
>> bumped to this commit revision. Do you confirm?
>>
>> Could you try the same test without modifying test.txt in rev 3?
>> I think you'll also see LastChangedRev 3 on subdir with 1.6.
>
> Interesting. The issue you reported is indeed similar, but it's more
> subtle than appears at first. There is a difference between 1.6 and
> 1.7, but *only in the committing working copy*, not in the repository.
> The behavior is also different if the WC is mixed-rev before the "svn
> mv", as opposed to uniform revision.
>
> 1) Uniform rev
>
> svnadmin create repos
> svn mkdir -mm $REPOS/dir # creates rev 1
> svn co $REPOS wc
> cd wc
> echo blah > dir/file.txt
> svn add dir/file.txt
> svn commit -mm # creates rev 2
> svn up # uniform rev 2
> svn mv dir dir2
> svn commit -mm # creates rev 3
>
> With 1.6:
> - In originating WC: LCR of file.txt is 3
> - In repository: LCR of file.txt is 2
>
> With 1.7:
> - In originating WC: LCR of file.txt is 2
> - In repository: LCR of file.txt is 2
>
> So I believe that 1.6's behavior in the working copy is indeed
> incorrect, and that the LCR of a child was always intended to be
> unaffected by the move/copy of a parent dir. That's the behavior of
> the repository, in both 1.6 and 1.7. What you saw with 1.6 (LCR 3 on
> file.txt) was only true in the originating working copy, which means
> that all other working copies will get LCR 2. Not good :-). And that
> has apparently been fixed in 1.7.
>
>
> 2) Mixed rev
>
> svnadmin create repos
> svn mkdir -mm $REPOS/dir # creates rev 1
> svn co $REPOS wc
> cd wc
> echo blah > dir/file.txt
> svn add dir/file.txt
> svn commit -mm # creates rev 2
> svn mv dir dir2
> svn commit -mm # *** out-of-date error
> svn up # tree conflict (only 1.6 [1])
> svn resolve --accept=working dir # only needed with 1.6
> svn commit -mm # creates rev 3
>
> With 1.6:
> - In originating WC: LCR of file.txt is 3
> - In repository: LCR of file.txt is 3
>
> With 1.7:
> - In originating WC: LCR of file.txt is 3
> - In repository: LCR of file.txt is 3
>
> So it seems the situation is different with a mixed revision scenario,
> but at least it's consistent between 1.6 and 1.7, and between
> originating WC and repository.
>
> Also, the notifications on commit are different between uniform rev
> and mixed-rev (same for 1.6 and 1.7):
>
> Uniform rev:
> Deleting dir
> Adding dir2
>
> Mixed rev:
> Deleting dir
> Adding dir2
> Adding dir2\test.txt
>
> (that just indicates to me that in the mixed-rev situation, something
> is done explicitly with test.txt (different working rev as parent
> dir), which might explain the bumping of LCR in this case)
>
>
> Conclusion: what you saw seems to be a bug in 1.6 (causing incorrect
> bumping of LCR in originating WC), which got fixed in 1.7. What I now
> found seems to be a similar bug introduced in 1.7 (incorrect
> non-bumping of LCR in intermediate subdir in originating WC).
Forgot the footnote:
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=3526 (Commit
of newly added file followed by move (or delete) of parent dir causes
tree conflict)
--
Johan
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Vincent Lefevre <vi...@vinc17.net>.
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@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 <vi...@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)
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jul 4, 2012 at 2:26 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Jul 4, 2012 at 2:11 PM, Vincent Lefevre <vi...@vinc17.net> wrote:
>> On 2012-07-04 13:58:50 +0200, Johan Corveleyn wrote:
>>> > The problem now is that the URL + the LastChangedRev together can
>>> > no longer identify the file, because the LastChangedRev can now be
>>> > incorrect as a peg revision.
>>>
>>> I'm afraid I don't follow you here either. Can you give a concrete example?
>>
>> Well, this is more complex that I thought, and 1.7 really has an
>> inconsistency. My example is in my reply to Philip Martin.
>
> Ah yes, you're right.
>
> 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).
I filed an issue for this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4203 (Commit of
moved dir with modified file in dir/subdir doesn't bump LastChangedRev
of subdir in originating WC)
--
Johan
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jul 4, 2012 at 2:11 PM, Vincent Lefevre <vi...@vinc17.net> wrote:
> On 2012-07-04 13:58:50 +0200, Johan Corveleyn wrote:
>> > The problem now is that the URL + the LastChangedRev together can
>> > no longer identify the file, because the LastChangedRev can now be
>> > incorrect as a peg revision.
>>
>> I'm afraid I don't follow you here either. Can you give a concrete example?
>
> Well, this is more complex that I thought, and 1.7 really has an
> inconsistency. My example is in my reply to Philip Martin.
Ah yes, you're right.
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. You
mentioned one concrete use-case which breaks down because of this:
being able to identify a file with URL@LCR (I'm not sure if this is
(or ever was) an intended use-case). Is there other behavior that
depends on this?
Now that I think about it: the current behavior of "LCR not bumped by
parent move/copy" is there at least since 1.5. 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...
--
Johan
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2012-07-04 13:58:50 +0200, Johan Corveleyn wrote:
> I don't understand. It's pretty clear that 1.6 is incorrect, because
> it puts a different LCR value in the originating working copy than in
> the repository.
Yes, 1.6 is incorrect, but 1.6 might have a regression compared
to 1.4 and/or 1.5. Or 1.4 and/or 1.5 were also incorrect and the
bug have never really been fixed. 1.7 is also incorrect if you
consider the URL (see my reply to Philip Martin).
> > The problem now is that the URL + the LastChangedRev together can
> > no longer identify the file, because the LastChangedRev can now be
> > incorrect as a peg revision.
>
> I'm afraid I don't follow you here either. Can you give a concrete example?
Well, this is more complex that I thought, and 1.7 really has an
inconsistency. My example is in my reply to Philip Martin.
--
Vincent Lefèvre <vi...@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)
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jul 4, 2012 at 1:24 PM, Vincent Lefevre <vi...@vinc17.net> wrote:
> On 2012-07-03 23:31:55 +0200, Johan Corveleyn wrote:
>> So I believe that 1.6's behavior in the working copy is indeed
>> incorrect, and that the LCR of a child was always intended to be
>> unaffected by the move/copy of a parent dir. That's the behavior of
>> the repository, in both 1.6 and 1.7. What you saw with 1.6 (LCR 3 on
>> file.txt) was only true in the originating working copy, which means
>> that all other working copies will get LCR 2. Not good :-). And that
>> has apparently been fixed in 1.7.
>
> Actually, in the past, this was not regarded as incorrect. There has
> already been a fix in 1.4 and 1.5 the other way around concerning
> this particular problem (in addition to other problems). See
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1743
>
> and the latest paragraph of my bug report (and the duplicates).
I don't understand. It's pretty clear that 1.6 is incorrect, because
it puts a different LCR value in the originating working copy than in
the repository. That can never be good, because other working copies
will get a different value. I haven't checked older versions, but they
may have the same problem. Just the inconsistency between originating
WC and repository is clearly wrong.
Now, whether or not the 1.6 originating WC is wrong, or the 1.6
repository is wrong, that's another matter of discussion. But in any
case 1.6 contains a bug here. In 1.7 the originating WC and repository
are at least the same (for your use case at least -- not for the other
edge case I brought up).
> The problem now is that the URL + the LastChangedRev together can
> no longer identify the file, because the LastChangedRev can now be
> incorrect as a peg revision.
I'm afraid I don't follow you here either. Can you give a concrete example?
My reasoning is as follows: it's ok that the LCR isn't affected by
moves of parent directories, because that's reflected in the URL
already. So if you take URL+LCR, that will still always correctly
identify the file, won't it?
--
Johan
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jul 04, 2012 at 03:39:37PM +0200, Vincent Lefevre wrote:
> But how does Subversion know that dir2/file@3 is the same object as
> dir1/file@2?
This is explained here:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/fs-history
Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir
Posted by Philip Martin <ph...@wandisco.com>.
Vincent Lefevre <vi...@vinc17.net> writes:
> But how does Subversion know that dir2/file@3 is the same object as
> dir1/file@2?
It has the same node-rev-id:
$ svnadmin create repo
$ svn import -mm repo/format file://`pwd`/repo/A/f
$ svn mv -mm file://`pwd`/repo/A ^/B
$ svnlook tree --show-ids -r1 repo
/ <0.0.r1/388>
A/ <0-1.0.r1/231>
f <2-1.0.r1/27>
$ svnlook tree --show-ids -r2 repo
/ <0.0.r2/177>
B/ <0-1.0-2.r2/0>
f <2-1.0.r1/27>
--
Cerified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2012-07-04 14:01:36 +0100, Philip Martin wrote:
> Vincent Lefevre <vi...@vinc17.net> writes:
>
> > On 2012-07-04 13:28:21 +0100, Philip Martin wrote:
> >>
> >> Where would the revision 3 come from? LastChangedRev is 2. That's what
> >> Subversion's cheap copy means.
> >
> > Yes, but I meant that LastChangedRev could be 3 after a move.
> > I don't think this contradicts cheap copy: when doing
> >
> > svn cat file:///tmp/my-test-svn/svn/dir2/file@3
> >
> > Subversion gets the file via a COPY node or something like that
> > (I don't know the exact internals) as the file hasn't changed,
> > and it could get LastChangedRev from it.
>
> No, it doesn't follow a copy. dir2@3 has a reference to the the same
> child object as dir1@2. dir2/file@3 is exactly the same object as
> dir1/file@2. That's what a cheap copy means.
But how does Subversion know that dir2/file@3 is the same object as
dir1/file@2? It must follow some reference, and if a LastChangedRev
is associated to each reference in the internal data structures,
Subversion will get the correct revision. At worst, you will only
lose a constant factor in time and memory.
> > My point is that <URL>@<LastChangedRev> should always be a valid
> > reference to the file, and it should be equivalent to <URL>@HEAD
> > or just <URL>.
>
> That's not the way it works. I think you want:
>
> -r<LastChangedRev> <URL>@<Revision>
>
> i.e. take the current URL@Revision and go back to LastChangedRev.
Well, I think that the Header keyword is really confusing because it
just gives <URL> and <LastChangedRev>, while if a URL and revision
are given together, one would expect <URL> and <Revision> (or some
equivalent value).
--
Vincent Lefèvre <vi...@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)
Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir
Posted by Philip Martin <ph...@wandisco.com>.
Vincent Lefevre <vi...@vinc17.net> writes:
> On 2012-07-04 13:28:21 +0100, Philip Martin wrote:
>>
>> Where would the revision 3 come from? LastChangedRev is 2. That's what
>> Subversion's cheap copy means.
>
> Yes, but I meant that LastChangedRev could be 3 after a move.
> I don't think this contradicts cheap copy: when doing
>
> svn cat file:///tmp/my-test-svn/svn/dir2/file@3
>
> Subversion gets the file via a COPY node or something like that
> (I don't know the exact internals) as the file hasn't changed,
> and it could get LastChangedRev from it.
No, it doesn't follow a copy. dir2@3 has a reference to the the same
child object as dir1@2. dir2/file@3 is exactly the same object as
dir1/file@2. That's what a cheap copy means.
If you make a commit that explicitly modifies dir2/file then the
node-rev-id of dir2/file will get a new copy-id but until that happens
it's the same node as dir1/file.
> My point is that <URL>@<LastChangedRev> should always be a valid
> reference to the file, and it should be equivalent to <URL>@HEAD
> or just <URL>.
That's not the way it works. I think you want:
-r<LastChangedRev> <URL>@<Revision>
i.e. take the current URL@Revision and go back to LastChangedRev.
--
Cerified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
RE: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Vincent Lefevre [mailto:vincent-svn@vinc17.net]
> Sent: woensdag 4 juli 2012 14:46
> To: dev@subversion.apache.org
> Subject: Re: Incorrect LastChangedRev in working copy after committing
> directory move + modified file in subdir
>
> On 2012-07-04 13:28:21 +0100, Philip Martin wrote:
> > Vincent Lefevre <vi...@vinc17.net> writes:
> > > The output ends with:
> > >
> > > + cat dir2/file
> > > $Header: file:///tmp/my-test-svn/svn/dir1/file 2 2012-07-04 11:57:43Z
> vlefevre $
> > > + svn cat file:///tmp/my-test-svn/svn/dir2/file@3
> > > $Header: file:///tmp/my-test-svn/svn/dir2/file 2 2012-07-04 11:57:43Z
> vlefevre $
> > >
> > > file:///tmp/my-test-svn/svn/dir1/file@2 exists but this isn't the
> > > real URL of the file.
> >
> > That's a keyword expansion bug, a variation on issue 1975.
> >
> > > file:///tmp/my-test-svn/svn/dir2/file@2 doesn't exist.
> > >
> > > IMHO, the most intuitive Header string should have
> > >
> > > file:///tmp/my-test-svn/svn/dir2/file 3
> >
> > Where would the revision 3 come from? LastChangedRev is 2. That's what
> > Subversion's cheap copy means.
>
> Yes, but I meant that LastChangedRev could be 3 after a move.
> I don't think this contradicts cheap copy: when doing
>
> svn cat file:///tmp/my-test-svn/svn/dir2/file@3
>
> Subversion gets the file via a COPY node or something like that
> (I don't know the exact internals) as the file hasn't changed,
> and it could get LastChangedRev from it.
>
> My point is that <URL>@<LastChangedRev> should always be a valid
> reference to the file, and it should be equivalent to <URL>@HEAD
> or just <URL>.
I think LastChangedRev should match the last changed rev of a plain
checkout.
I know there are problems in getting there, but your answer that
URL@LastChangedRev should work, would tell me that you think it is broken
for clean checkouts that contain files that were copied via their parent.
URL@revision -r <LastChangedRev> should get you the file as and at where it
was last changed
And URL@revision gives you a location that you can checkout from directly.
Bert
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2012-07-04 13:28:21 +0100, Philip Martin wrote:
> Vincent Lefevre <vi...@vinc17.net> writes:
> > The output ends with:
> >
> > + cat dir2/file
> > $Header: file:///tmp/my-test-svn/svn/dir1/file 2 2012-07-04 11:57:43Z vlefevre $
> > + svn cat file:///tmp/my-test-svn/svn/dir2/file@3
> > $Header: file:///tmp/my-test-svn/svn/dir2/file 2 2012-07-04 11:57:43Z vlefevre $
> >
> > file:///tmp/my-test-svn/svn/dir1/file@2 exists but this isn't the
> > real URL of the file.
>
> That's a keyword expansion bug, a variation on issue 1975.
>
> > file:///tmp/my-test-svn/svn/dir2/file@2 doesn't exist.
> >
> > IMHO, the most intuitive Header string should have
> >
> > file:///tmp/my-test-svn/svn/dir2/file 3
>
> Where would the revision 3 come from? LastChangedRev is 2. That's what
> Subversion's cheap copy means.
Yes, but I meant that LastChangedRev could be 3 after a move.
I don't think this contradicts cheap copy: when doing
svn cat file:///tmp/my-test-svn/svn/dir2/file@3
Subversion gets the file via a COPY node or something like that
(I don't know the exact internals) as the file hasn't changed,
and it could get LastChangedRev from it.
My point is that <URL>@<LastChangedRev> should always be a valid
reference to the file, and it should be equivalent to <URL>@HEAD
or just <URL>.
--
Vincent Lefèvre <vi...@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)
Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir
Posted by Philip Martin <ph...@wandisco.com>.
Vincent Lefevre <vi...@vinc17.net> writes:
> Anyway the URL of every file should be updated, shouldn't it?
> At least there is an inconsistency, shown by the following script:
[...]
> The output ends with:
>
> + cat dir2/file
> $Header: file:///tmp/my-test-svn/svn/dir1/file 2 2012-07-04 11:57:43Z vlefevre $
> + svn cat file:///tmp/my-test-svn/svn/dir2/file@3
> $Header: file:///tmp/my-test-svn/svn/dir2/file 2 2012-07-04 11:57:43Z vlefevre $
>
> file:///tmp/my-test-svn/svn/dir1/file@2 exists but this isn't the
> real URL of the file.
That's a keyword expansion bug, a variation on issue 1975.
> file:///tmp/my-test-svn/svn/dir2/file@2 doesn't exist.
>
> IMHO, the most intuitive Header string should have
>
> file:///tmp/my-test-svn/svn/dir2/file 3
Where would the revision 3 come from? LastChangedRev is 2. That's what
Subversion's cheap copy means.
LastChangedRev is the only revision we have, apart from the "current"
revision see:
http://subversion.apache.org/faq.html#version-value-in-source
--
Cerified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2012-07-04 12:51:13 +0100, Philip Martin wrote:
> If you are saying that a move should update the LastChangedRev of every
> file (and dir?) in the destination then that would break the cheap copy
> feature of Subversion's copy-on-write filesystem.
Anyway the URL of every file should be updated, shouldn't it?
At least there is an inconsistency, shown by the following script:
------------------------------------------------------------
#!/bin/sh
set -ex
svn --version
mkdir my-test-svn
cd my-test-svn
svnadmin create svn
root=file://`pwd`/svn
svn co "$root" wc
cd wc
svn mkdir dir1
svn ci -m 'add dir1'
printf '\044Header\044\n' > dir1/file
svn add dir1/file
svn ps svn:keywords Header dir1/file
svn ci -m 'add dir1/file'
cat dir1/file
svn cat "$root/dir1/file@2"
svn up
svn mv dir1 dir2
svn ci -m 'mv dir1 dir2'
svn info dir2/file
cat dir2/file
svn cat "$root/dir2/file@3"
cd ../..
rm -rf my-test-svn
------------------------------------------------------------
The output ends with:
+ cat dir2/file
$Header: file:///tmp/my-test-svn/svn/dir1/file 2 2012-07-04 11:57:43Z vlefevre $
+ svn cat file:///tmp/my-test-svn/svn/dir2/file@3
$Header: file:///tmp/my-test-svn/svn/dir2/file 2 2012-07-04 11:57:43Z vlefevre $
file:///tmp/my-test-svn/svn/dir1/file@2 exists but this isn't the
real URL of the file.
file:///tmp/my-test-svn/svn/dir2/file@2 doesn't exist.
IMHO, the most intuitive Header string should have
file:///tmp/my-test-svn/svn/dir2/file 3
(correct URL, and a revision that is valid for this URL).
Full output attached.
--
Vincent Lef�vre <vi...@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)
Re: Incorrect LastChangedRev in working copy after committing directory
move + modified file in subdir
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/04/2012 07:51 AM, Philip Martin wrote:
> If you are saying that a move should update the LastChangedRev of every
> file (and dir?) in the destination then that would break the cheap copy
> feature of Subversion's copy-on-write filesystem.
Guys, let's clarify some things.
First, this whole concept of a last-changed-rev (LCR) originates *outside*
the versioned filesystem (FS). The FS has a low-level construct known as a
created-rev, but while that information is used by the server to reveal the
LCR to the client, they are not identical constructs, nor were they intended
to be.
LCR exists solely for keyword expansion, and that only so folks can compare
two versions of a working file and know that they aren't the same revision.
Finally, (LCR, URL) was never intended to be used a unique coordinate pair
for identifying resources. That it work out as such most of the time might
be a benefit, but was not a feature designed into the system.
So, no, for the purposes of this discussion, moves should continue to employ
cheap copies in the FS, because the FS created-rev is entirely outside the
scope of this LCR business. And if we're going to actively chase the goal
of using (LCR, URL) as a valid coordinate pair, that's fine, but it needs to
happen as part of an overall effort to clarify the historically shady
definitions of these keyword expansion values.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir
Posted by Philip Martin <ph...@wandisco.com>.
Vincent Lefevre <vi...@vinc17.net> writes:
> On 2012-07-03 23:31:55 +0200, Johan Corveleyn wrote:
>> So I believe that 1.6's behavior in the working copy is indeed
>> incorrect, and that the LCR of a child was always intended to be
>> unaffected by the move/copy of a parent dir. That's the behavior of
>> the repository, in both 1.6 and 1.7. What you saw with 1.6 (LCR 3 on
>> file.txt) was only true in the originating working copy, which means
>> that all other working copies will get LCR 2. Not good :-). And that
>> has apparently been fixed in 1.7.
>
> Actually, in the past, this was not regarded as incorrect. There has
> already been a fix in 1.4 and 1.5 the other way around concerning
> this particular problem (in addition to other problems). See
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1743
>
> and the latest paragraph of my bug report (and the duplicates).
>
> The problem now is that the URL + the LastChangedRev together can
> no longer identify the file, because the LastChangedRev can now be
> incorrect as a peg revision.
If you are saying that a move should update the LastChangedRev of every
file (and dir?) in the destination then that would break the cheap copy
feature of Subversion's copy-on-write filesystem.
--
Cerified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2012-07-03 23:31:55 +0200, Johan Corveleyn wrote:
> So I believe that 1.6's behavior in the working copy is indeed
> incorrect, and that the LCR of a child was always intended to be
> unaffected by the move/copy of a parent dir. That's the behavior of
> the repository, in both 1.6 and 1.7. What you saw with 1.6 (LCR 3 on
> file.txt) was only true in the originating working copy, which means
> that all other working copies will get LCR 2. Not good :-). And that
> has apparently been fixed in 1.7.
Actually, in the past, this was not regarded as incorrect. There has
already been a fix in 1.4 and 1.5 the other way around concerning
this particular problem (in addition to other problems). See
http://subversion.tigris.org/issues/show_bug.cgi?id=1743
and the latest paragraph of my bug report (and the duplicates).
The problem now is that the URL + the LastChangedRev together can
no longer identify the file, because the LastChangedRev can now be
incorrect as a peg revision.
--
Vincent Lefèvre <vi...@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)
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Jul 3, 2012 at 2:09 PM, Vincent Lefevre <vi...@vinc17.net> wrote:
> On 2012-07-03 13:21:35 +0200, Johan Corveleyn wrote:
>> I just tested my scenario with 1.6: it doesn't have the same issue
>> (subdir has LastChangedRev 3 in both the working copy and the
>> repository). So this is a regression in 1.7.
>
> The reason why "subdir" has LastChangedRev 3 may be because its parent
> directory "dir" was renamed to "dir2": with Subversion 1.6, when a
> directory was copied, all its descendents had their LastChangedRev
> bumped to this commit revision. Do you confirm?
>
> Could you try the same test without modifying test.txt in rev 3?
> I think you'll also see LastChangedRev 3 on subdir with 1.6.
Interesting. The issue you reported is indeed similar, but it's more
subtle than appears at first. There is a difference between 1.6 and
1.7, but *only in the committing working copy*, not in the repository.
The behavior is also different if the WC is mixed-rev before the "svn
mv", as opposed to uniform revision.
1) Uniform rev
svnadmin create repos
svn mkdir -mm $REPOS/dir # creates rev 1
svn co $REPOS wc
cd wc
echo blah > dir/file.txt
svn add dir/file.txt
svn commit -mm # creates rev 2
svn up # uniform rev 2
svn mv dir dir2
svn commit -mm # creates rev 3
With 1.6:
- In originating WC: LCR of file.txt is 3
- In repository: LCR of file.txt is 2
With 1.7:
- In originating WC: LCR of file.txt is 2
- In repository: LCR of file.txt is 2
So I believe that 1.6's behavior in the working copy is indeed
incorrect, and that the LCR of a child was always intended to be
unaffected by the move/copy of a parent dir. That's the behavior of
the repository, in both 1.6 and 1.7. What you saw with 1.6 (LCR 3 on
file.txt) was only true in the originating working copy, which means
that all other working copies will get LCR 2. Not good :-). And that
has apparently been fixed in 1.7.
2) Mixed rev
svnadmin create repos
svn mkdir -mm $REPOS/dir # creates rev 1
svn co $REPOS wc
cd wc
echo blah > dir/file.txt
svn add dir/file.txt
svn commit -mm # creates rev 2
svn mv dir dir2
svn commit -mm # *** out-of-date error
svn up # tree conflict (only 1.6 [1])
svn resolve --accept=working dir # only needed with 1.6
svn commit -mm # creates rev 3
With 1.6:
- In originating WC: LCR of file.txt is 3
- In repository: LCR of file.txt is 3
With 1.7:
- In originating WC: LCR of file.txt is 3
- In repository: LCR of file.txt is 3
So it seems the situation is different with a mixed revision scenario,
but at least it's consistent between 1.6 and 1.7, and between
originating WC and repository.
Also, the notifications on commit are different between uniform rev
and mixed-rev (same for 1.6 and 1.7):
Uniform rev:
Deleting dir
Adding dir2
Mixed rev:
Deleting dir
Adding dir2
Adding dir2\test.txt
(that just indicates to me that in the mixed-rev situation, something
is done explicitly with test.txt (different working rev as parent
dir), which might explain the bumping of LCR in this case)
Conclusion: what you saw seems to be a bug in 1.6 (causing incorrect
bumping of LCR in originating WC), which got fixed in 1.7. What I now
found seems to be a similar bug introduced in 1.7 (incorrect
non-bumping of LCR in intermediate subdir in originating WC).
--
Johan
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2012-07-03 13:21:35 +0200, Johan Corveleyn wrote:
> I just tested my scenario with 1.6: it doesn't have the same issue
> (subdir has LastChangedRev 3 in both the working copy and the
> repository). So this is a regression in 1.7.
The reason why "subdir" has LastChangedRev 3 may be because its parent
directory "dir" was renamed to "dir2": with Subversion 1.6, when a
directory was copied, all its descendents had their LastChangedRev
bumped to this commit revision. Do you confirm?
Could you try the same test without modifying test.txt in rev 3?
I think you'll also see LastChangedRev 3 on subdir with 1.6.
--
Vincent Lefèvre <vi...@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)
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Jul 3, 2012 at 1:15 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Tue, Jul 3, 2012 at 12:56 PM, Vincent Lefevre <vi...@vinc17.net> wrote:
>> On 2012-06-27 16:33:23 +0200, Johan Corveleyn wrote:
>>> I noticed this while investigating (other) problems with incorrect
>>> LastChangedRev's (subtle form of working copy corruption):
>>
>> It seems to be the same thing I had reported here:
>>
>> http://mail-archives.apache.org/mod_mbox/subversion-dev/201206.mbox/%3C20120619010211.GE5263%40xvii.vinc17.org%3E
>>
>> and
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678075
>
> No, it's not the same issue (the issue you reported is, let's say,
> open for discussion, and I don't think the 1.7 behavior is wrong ...
> it's just different from 1.6).
>
> The issue I'm reporting in this thread is that the LastChangedRev
> differs between 'svn info subdir' and 'svn info
> url-of-subdir@workingrev-of-subdir'. That seems wrong, it means that
> the working copy (from where the move was committed) has a
> LastChangedRev that's different from the repository and from any other
> working copy that's checked out (from that same working revision).
>
> Note that this is only the LastChangedRev of the intermediate subdir
> which I'm talking about, so I don't think there's an impact on Keyword
> Substitution.
I just tested my scenario with 1.6: it doesn't have the same issue
(subdir has LastChangedRev 3 in both the working copy and the
repository). So this is a regression in 1.7.
--
Johan
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2012-07-03 13:15:33 +0200, Johan Corveleyn wrote:
> No, it's not the same issue (the issue you reported is, let's say,
> open for discussion, and I don't think the 1.7 behavior is wrong ...
> it's just different from 1.6).
OK, I actually focused on "svn info .../subdir", where you get
"Last Changed Rev: 2" with svn 1.7.5 while with svn 1.6.x, one
would have got 3 (because the subdir parent moved at rev 3),
and this corresponded to what I reported.
Now in your case, you also modify test.txt in subdir. After some
tests, it seems that the LastChanged* metadata of a directory are
updated whenever something has changed below the directory (except
in particular cases as you reported). This is something I didn't
notice before, even though it is the same behavior as with 1.6.x.
So, according to this behavior, one would expect 3.
I would say that the main problem is that the LastChanged* metadata
are underspecified. The Subversion book doesn't seem to specify
anything except for keyword substitution, where it says:
This keyword describes the last known revision in which this file
changed in the repository, and looks something like $Revision: 144 $.
It may also be specified as LastChangedRevision or Rev.
But a change of the contents of a file isn't a change of the directory
that contains it (neither of any of its ancestors). So, the current
behavior of "svn info" on directories would be incorrect in most cases.
> The issue I'm reporting in this thread is that the LastChangedRev
> differs between 'svn info subdir' and 'svn info
> url-of-subdir@workingrev-of-subdir'. That seems wrong, it means that
> the working copy (from where the move was committed) has a
> LastChangedRev that's different from the repository and from any other
> working copy that's checked out (from that same working revision).
Actually I would say that "svn info subdir" is correct, and all the
other cases are incorrect.
> Note that this is only the LastChangedRev of the intermediate subdir
> which I'm talking about, so I don't think there's an impact on Keyword
> Substitution.
Yes, the issue is specific to directories, for which there are no
possible keyword substitutions.
--
Vincent Lefèvre <vi...@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)
Re: Incorrect LastChangedRev in working copy after committing
directory move + modified file in subdir
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Jul 3, 2012 at 12:56 PM, Vincent Lefevre <vi...@vinc17.net> wrote:
> On 2012-06-27 16:33:23 +0200, Johan Corveleyn wrote:
>> I noticed this while investigating (other) problems with incorrect
>> LastChangedRev's (subtle form of working copy corruption):
>
> It seems to be the same thing I had reported here:
>
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201206.mbox/%3C20120619010211.GE5263%40xvii.vinc17.org%3E
>
> and
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678075
No, it's not the same issue (the issue you reported is, let's say,
open for discussion, and I don't think the 1.7 behavior is wrong ...
it's just different from 1.6).
The issue I'm reporting in this thread is that the LastChangedRev
differs between 'svn info subdir' and 'svn info
url-of-subdir@workingrev-of-subdir'. That seems wrong, it means that
the working copy (from where the move was committed) has a
LastChangedRev that's different from the repository and from any other
working copy that's checked out (from that same working revision).
Note that this is only the LastChangedRev of the intermediate subdir
which I'm talking about, so I don't think there's an impact on Keyword
Substitution.
--
Johan