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

[Johan Corveleyn]

On Wed, Jul 4, 2012 at 2:26 PM, Johan Corveleyn  wrote:
> On Wed, Jul 4, 2012 at 2:11 PM, Vincent Lefevre  
> 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

[C. Michael Pilato]

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 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development





signature.asc
Description: OpenPGP digital signature

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

[Philip Martin]

Vincent Lefevre  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

[Stefan Sperling]

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

[Vincent Lefevre]

On 2012-07-04 14:01:36 +0100, Philip Martin wrote:
> Vincent Lefevre  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 @ should always be a valid
> > reference to the file, and it should be equivalent to @HEAD
> > or just .
> 
> That's not the way it works.  I think you want:
> 
>-r @
> 
> 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  and , while if a URL and revision
are given together, one would expect  and  (or some
equivalent value).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - 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

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - 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

[Philip Martin]

Vincent Lefevre  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 @ should always be a valid
> reference to the file, and it should be equivalent to @HEAD
> or just .

That's not the way it works.  I think you want:

   -r @

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

[Bert Huijben]

> -Original Message-
> From: Vincent Lefevre [mailto:vincent-...@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  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 @ should always be a valid
> reference to the file, and it should be equivalent to @HEAD
> or just .

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

[Vincent Lefevre]

On 2012-07-04 13:28:21 +0100, Philip Martin wrote:
> Vincent Lefevre  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 @ should always be a valid
reference to the file, and it should be equivalent to @HEAD
or just .

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - 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

[Philip Martin]

Vincent Lefevre  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

[Johan Corveleyn]

On Wed, Jul 4, 2012 at 2:11 PM, Vincent Lefevre  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

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - 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

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
+ svn --version
svn, version 1.7.5 (r1336830)
   compiled Jun 17 2012, 07:52:38

Copyright (C) 2012 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - handles 'http' scheme
  - handles 'https' scheme

+ mkdir my-test-svn
+ cd my-test-svn
+ svnadmin create svn
+ pwd
+ root=file:///tmp/my-test-svn/svn
+ svn co file:///tmp/my-test-svn/svn wc
Checked out revision 0.
+ cd wc
+ svn mkdir dir1
A dir1
+ svn ci -m add dir1
Adding dir1

Committed revision 1.
+ printf \044Header\044\n
+ svn add dir1/file
A dir1/file
+ svn ps svn:keywords Header dir1/file
property 'svn:keywords' set on 'dir1/file'
+ svn ci -m add dir1/file
Adding dir1/file
Transmitting file data .
Committed revision 2.
+ cat dir1/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/dir1/file@2
$Header: file:///tmp/my-test-svn/svn/dir1/file 2 2012-07-04 11:57:43Z vlefevre $
+ svn up
Updating '.':
At revision 2.
+ svn mv dir1 dir2
A dir2
D dir1
D dir1/file
+ svn ci -m mv dir1 dir2
Deleting   dir1
Adding dir2

Committed revision 3.
+ svn info dir2/file
Path: dir2/file
Name: file
Working Copy Root Path: /tmp/my-test-svn/wc
URL: file:///tmp/my-test-svn/svn/dir2/file
Repository Root: file:///tmp/my-test-svn/svn
Repository UUID: d7bbc0d2-1977-4b50-a670-ad8c8a0c08df
Revision: 3
Node Kind: file
Schedule: normal
Last Changed Author: vlefevre
Last Changed Rev: 2
Last Changed Date: 2012-07-04 13:57:43 +0200 (Wed, 04 Jul 2012)
Text Last Updated: 2012-07-04 13:57:43 +0200 (Wed, 04 Jul 2012)
Checksum: 074821f52733e39ab981a36c5e46748b8ebbbc75

+ 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 $
+ cd ../..
+ rm -rf my-test-svn

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

[Johan Corveleyn]

On Wed, Jul 4, 2012 at 1:24 PM, Vincent Lefevre  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

[Philip Martin]

Vincent Lefevre  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

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - 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

[Johan Corveleyn]

On Tue, Jul 3, 2012 at 11:31 PM, Johan Corveleyn  wrote:
> On Tue, Jul 3, 2012 at 2:09 PM, Vincent Lefevre  
> 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

[Johan Corveleyn]

On Tue, Jul 3, 2012 at 2:09 PM, Vincent Lefevre  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

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - 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

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - 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

[Johan Corveleyn]

On Tue, Jul 3, 2012 at 1:15 PM, Johan Corveleyn  wrote:
> On Tue, Jul 3, 2012 at 12:56 PM, Vincent Lefevre  
> 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

[Johan Corveleyn]

On Tue, Jul 3, 2012 at 12:56 PM, Vincent Lefevre  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

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

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - 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

[Johan Corveleyn]

On Thu, Jun 28, 2012 at 11:58 AM, Bert Huijben  wrote:
>
>
>> -Original Message-
>> From: Johan Corveleyn [mailto:jcor...@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  wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Johan Corveleyn [mailto:jcor...@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 reposi

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

[Bert Huijben]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@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  wrote:
> >
> >
> >> -Original Message-
> >> From: Johan Corveleyn [mailto:jcor...@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 fil

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

[Johan Corveleyn]

On Wed, Jun 27, 2012 at 7:48 PM, Bert Huijben  wrote:
>
>
>> -Original Message-
>> From: Johan Corveleyn [mailto:jcor...@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@REV (where REV is the working revision
from the working copy).

-- 
Johan

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

[Bert Huijben]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@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
> Awc\dir
> Awc\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
> Sendingwc\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

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

[Johan Corveleyn]

On Wed, Jun 27, 2012 at 4:33 PM, Johan Corveleyn  wrote:
> 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).

Forgot to mention: the above is with 1.7.5 (SlikSVN). I'll try with
trunk sometime later.

-- 
Johan

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

[Johan Corveleyn]

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
Awc\dir
Awc\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
Sendingwc\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).

-- 
Johan