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: svn commit: r1357214 - in /subversion/trunk/subversion: libsvn_wc/conflicts.c libsvn_wc/merge.c libsvn_wc/props.c tests/cmdline/merge_tests.py

[Bert Huijben]

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: woensdag 4 juli 2012 12:39
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1357214 - in /subversion/trunk/subversion:
> libsvn_wc/conflicts.c libsvn_wc/merge.c libsvn_wc/props.c
> tests/cmdline/merge_tests.py
> 
> On Wed, Jul 04, 2012 at 10:25:00AM -, rhuij...@apache.org wrote:
> > Author: rhuijben
> > Date: Wed Jul  4 10:24:58 2012
> > New Revision: 1357214
> >
> > URL: http://svn.apache.org/viewvc?rev=1357214&view=rev
> > Log:
> > Make it an error to perform a text or property merge into an already
> conflicted
> > node. We can't store two conflicts of the same kind on a node.
> > (And even if we could, it would be very hard to provide a UI to resolve
the
> >  conflict).
> >
> > 'svn merge' should probably provide some more user friendly handling for
> this
> > case. Just blocking merging into a somewhere conflicted tree currently
> breaks
> > a lot of tests, while it is certainly *not* best practice to merge into
a
> > conflicted tree.
> 
> Can we add an --allow-conflicts switch that overrides this new error,
> like we did for mixed-revisions? That might also make it easier to keep
> the merge tests passing by adding the new flag where appropriate.

That would work for the high-level check, that I couldn't commit because it
would break all kinds of other scenarios.

Low level (where this change was) we should really error on this case and
ask the merge code to resolve the conflict before calling into the merge
code. (Like how it currently handles tree conflicts)

Before this change was applied we just ignored the conflict and wrote a new
conflict right over it. (And we probably did that for several versions).

I do think we should check for conflicts on merging like we do for mixed
revision working copies, but that is outside my current scope of the
conflict handling.

(The status walk in the merge code already does all the hard work, it is
just passing the information to the user. The patch to do that was so small
that I just deleted it, instead of keeping it for future work)

Bert

Re: svn commit: r1357214 - in /subversion/trunk/subversion: libsvn_wc/conflicts.c libsvn_wc/merge.c libsvn_wc/props.c tests/cmdline/merge_tests.py

[Stefan Sperling]

On Wed, Jul 04, 2012 at 10:25:00AM -, rhuij...@apache.org wrote:
> Author: rhuijben
> Date: Wed Jul  4 10:24:58 2012
> New Revision: 1357214
> 
> URL: http://svn.apache.org/viewvc?rev=1357214&view=rev
> Log:
> Make it an error to perform a text or property merge into an already 
> conflicted
> node. We can't store two conflicts of the same kind on a node.
> (And even if we could, it would be very hard to provide a UI to resolve the
>  conflict).
> 
> 'svn merge' should probably provide some more user friendly handling for this
> case. Just blocking merging into a somewhere conflicted tree currently breaks
> a lot of tests, while it is certainly *not* best practice to merge into a
> conflicted tree.

Can we add an --allow-conflicts switch that overrides this new error,
like we did for mixed-revisions? That might also make it easier to keep
the merge tests passing by adding the new flag where appropriate.