You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2008/10/29 15:58:45 UTC
Tree conflict bug?
Using current trunk. I am doing some basic testing so I can figure
out JavaHL changes to make around the status/info reporting etc.
I renamed a file and committed it.
In second WC, I made some edits to file and then did update. This
reported the tree conflict. I saw stuff like this:
$ svn st
M C trunk/src/com/acme/ui/editors/ColorManager.java
M trunk/src/com/acme/ui/editors/MyColorManager.java
$ svn info trunk/src/com/acme/ui/editors/ColorManager.java
Path: trunk/src/com/acme/ui/editors/ColorManager.java
Name: ColorManager.java
URL: file:///Users/mphippard/repositories/svn-1.6/trunk/src/com/acme/ui/editors/ColorManager.java
Repository Root: file:///Users/mphippard/repositories/svn-1.6
Repository UUID: a0b8b0e8-12cc-4994-9ac8-95a1682d52c6
Revision: 4
Node Kind: file
Schedule: normal
Last Changed Author: mphippard
Last Changed Rev: 3
Last Changed Date: 2008-10-29 11:44:29 -0400 (Wed, 29 Oct 2008)
Text Last Updated: 2008-10-29 11:45:02 -0400 (Wed, 29 Oct 2008)
Checksum: df4e1705289bff7b74b555fa1ffc549d
Tree conflict:
The update attempted to delete 'ColorManager.java'
(possibly as part of a rename operation).
You have edited 'ColorManager.java' locally.
What I am concerned about is that this file "ColorManager.java" still
appears to be a versioned file when in fact it no longer exists in the
repository. In my example, the edits I made to this file were
actually automatically transferred to the new file ... Cool!. So what
do I do here? I guess maybe svn resolve would have done the right
thing?
I did svn revert and the bug I am reporting is that this left
ColorManager.java in my WC with a status of "Normal". So I edited the
file and tried to commit and of course get the message that the file
does not exist. So the bug is that the WC was not handled properly.
My expectation was that svn revert would leave the file in the WC in
an Unversioned status.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Stephen Butler <sb...@elego.de>.
Quoting Mark Phippard <ma...@gmail.com>:
> On Wed, Oct 29, 2008 at 12:18 PM, Stephen Butler <sb...@elego.de> wrote:
>>> So what
>>> do I do here? I guess maybe svn resolve would have done the right
>>> thing?
>>
>> We haven't hooked up tree conflicts into the interactive conflict
>> resolution yet. 'svn resolved' will remove the tree conflict from
>> the file and allow the update to proceed.
>
> So "will" means in the future, not right now? I cannot seem to get it
> to do anything.
We're changing the tree conflict code to use the victim path in all
cases (earlier, we used the parent path to show status, info, etc.)
On trunk right now, 'svn resolved' still needs the parent path as
its argument. I'll fix that.
>
> Setting aside interactive resolution, I was OK with how update ran in
> general. I just do not see how to get rid of this file from my WC.
>
>>> I did svn revert and the bug I am reporting is that this left
>>> ColorManager.java in my WC with a status of "Normal". So I edited the
>>> file and tried to commit and of course get the message that the file
>>> does not exist. So the bug is that the WC was not handled properly.
>>>
>>> My expectation was that svn revert would leave the file in the WC in
>>> an Unversioned status.
>>
>> The incoming deletion of ColorManager.java was skipped due to the
>> tree conflict. 'svn info -uv' should show that ColorManager.java
>> is still at the old BASE version, and that it has incoming changes.
>
> -u is not an option for svn info.
Whoops, I meant 'svn status -uv'.
Regards,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Oct 29, 2008 at 12:18 PM, Stephen Butler <sb...@elego.de> wrote:
>> So what
>> do I do here? I guess maybe svn resolve would have done the right
>> thing?
>
> We haven't hooked up tree conflicts into the interactive conflict
> resolution yet. 'svn resolved' will remove the tree conflict from
> the file and allow the update to proceed.
So "will" means in the future, not right now? I cannot seem to get it
to do anything.
Setting aside interactive resolution, I was OK with how update ran in
general. I just do not see how to get rid of this file from my WC.
>> I did svn revert and the bug I am reporting is that this left
>> ColorManager.java in my WC with a status of "Normal". So I edited the
>> file and tried to commit and of course get the message that the file
>> does not exist. So the bug is that the WC was not handled properly.
>>
>> My expectation was that svn revert would leave the file in the WC in
>> an Unversioned status.
>
> The incoming deletion of ColorManager.java was skipped due to the
> tree conflict. 'svn info -uv' should show that ColorManager.java
> is still at the old BASE version, and that it has incoming changes.
-u is not an option for svn info.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Stephen Butler <sb...@elego.de>.
Quoting Mark Phippard <ma...@gmail.com>:
> Using current trunk. I am doing some basic testing so I can figure
> out JavaHL changes to make around the status/info reporting etc.
>
> I renamed a file and committed it.
>
> In second WC, I made some edits to file and then did update. This
> reported the tree conflict. I saw stuff like this:
>
> $ svn st
> M C trunk/src/com/acme/ui/editors/ColorManager.java
> M trunk/src/com/acme/ui/editors/MyColorManager.java
>
> $ svn info trunk/src/com/acme/ui/editors/ColorManager.java
> Path: trunk/src/com/acme/ui/editors/ColorManager.java
[...]
> Tree conflict:
> The update attempted to delete 'ColorManager.java'
> (possibly as part of a rename operation).
> You have edited 'ColorManager.java' locally.
>
>
> What I am concerned about is that this file "ColorManager.java" still
> appears to be a versioned file when in fact it no longer exists in the
> repository. In my example, the edits I made to this file were
> actually automatically transferred to the new file ... Cool!.
Hi Mark,
That's a special-case behavior added before the general tree conflict
effort started. We'd like to make tree conflict resolution
automatic where possible (subject to config).
> So what
> do I do here? I guess maybe svn resolve would have done the right
> thing?
We haven't hooked up tree conflicts into the interactive conflict
resolution yet. 'svn resolved' will remove the tree conflict from
the file and allow the update to proceed.
>
> I did svn revert and the bug I am reporting is that this left
> ColorManager.java in my WC with a status of "Normal". So I edited the
> file and tried to commit and of course get the message that the file
> does not exist. So the bug is that the WC was not handled properly.
>
> My expectation was that svn revert would leave the file in the WC in
> an Unversioned status.
The incoming deletion of ColorManager.java was skipped due to the
tree conflict. 'svn info -uv' should show that ColorManager.java
is still at the old BASE version, and that it has incoming changes.
A similar situation occurs in stat_tests.py 31 (file 'rho'). There's
a bug currently, in that the BASE is updated despite the conflict.
We're rewriting the "skipping" code at the moment to make it consistent
for all tree conflicts.
Regards,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Nov 03, 2008 at 03:30:48AM +0100, Neels J. Hofmeyr wrote:
>
>
> Stefan Sperling wrote:
> > See
> > http://subversion.tigris.org/svn_1.5_releasenotes.html#copy-move-improvements
> >
> >> So getting the local mods in there is more like, say, an accident, right? Is
> >> this always safe? Is it checked to be?
> >
> > Retaining the local mods is the goal of this feature.
>
> Ah. :)
>
> So this should actually auto-resolve a tree-conflict, somehow. In the nature
> of tree-conflicts, there must first be some blocking though, letting the
> change happen once the user acknowledges it. Ok, we know that by now. ;)
I think we should transfer local mods to moved files automatically.
I'm not sure about copies. Mercurial does transfer local mods made
to a file X to all copies of X coming in during an update. But I suspect
they do this mostly to handle the move case (they have, like us, the
broken model that a move equals copy+delete).
But until we have proper moves *cough*, we might as well do what
Mercurial does (which is still much smarter than keeping the local
mods in the file at the source path of the move operation.)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Stefan Sperling wrote:
> See
> http://subversion.tigris.org/svn_1.5_releasenotes.html#copy-move-improvements
>
>> So getting the local mods in there is more like, say, an accident, right? Is
>> this always safe? Is it checked to be?
>
> Retaining the local mods is the goal of this feature.
Ah. :)
So this should actually auto-resolve a tree-conflict, somehow. In the nature
of tree-conflicts, there must first be some blocking though, letting the
change happen once the user acknowledges it. Ok, we know that by now. ;)
$ svn up
C(D->M) file
A file_moved_here
### the local mods should not yet be in file_moved_here at this point!
$ svn ci
"No."
$ svn resolve --theirs-but-my-mods file <-- ick.
D file
M file_moved_here
Or something.
$ svn resolve --move file --to file_moved_here <-- also ick.
$ svn resolve --move file <-- needs copy-to info?
BTW, still just trying to understand it...
~Neels
Re: Tree conflict bug?
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Nov 01, 2008 at 02:10:44AM +0100, Neels J. Hofmeyr wrote:
>
>
> Stephen Butler wrote:
> >>>>> In my example, the edits I made to this file were
> >>>>> actually automatically transferred to the new file ... Cool!.
> >>>> Wow, I wish I knew why :)
> >>
> >> Yeah, Steve, explain :)
> >
> > See update_tests.py 37-40 ("update should make use of copyfrom
> > args").
> >
> > In the second WC, if the new file is added before the old file is
> > deleted, then we use the old file as the source instead of asking
> > the repo. The magic is in add_file_with_history() and in
> > locate_copyfrom(). Blame tells me the magician was sussman, about
> > a year ago.
> >
> > If you include both files in a single commit, you tend not to
> > get the magic. For instance, in our tree conflict tests it
> > doesn't happen.
>
> Am I understanding this right: Instead of downloading the new file from the
> server, it uses some prior knowledge and assumes that the file on disk is
> actually what would be downloaded, and uses that instead?
See
http://subversion.tigris.org/svn_1.5_releasenotes.html#copy-move-improvements
> So getting the local mods in there is more like, say, an accident, right? Is
> this always safe? Is it checked to be?
Retaining the local mods is the goal of this feature.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Stephen Butler wrote:
>>>>> In my example, the edits I made to this file were
>>>>> actually automatically transferred to the new file ... Cool!.
>>>> Wow, I wish I knew why :)
>>
>> Yeah, Steve, explain :)
>
> See update_tests.py 37-40 ("update should make use of copyfrom
> args").
>
> In the second WC, if the new file is added before the old file is
> deleted, then we use the old file as the source instead of asking
> the repo. The magic is in add_file_with_history() and in
> locate_copyfrom(). Blame tells me the magician was sussman, about
> a year ago.
>
> If you include both files in a single commit, you tend not to
> get the magic. For instance, in our tree conflict tests it
> doesn't happen.
Am I understanding this right: Instead of downloading the new file from the
server, it uses some prior knowledge and assumes that the file on disk is
actually what would be downloaded, and uses that instead?
So getting the local mods in there is more like, say, an accident, right? Is
this always safe? Is it checked to be?
Thanks
~Neels
Re: Tree conflict bug?
Posted by Stephen Butler <sb...@elego.de>.
Quoting "Neels J. Hofmeyr" <ne...@elego.de>:
>
>
> Mark Phippard wrote:
>> On Wed, Oct 29, 2008 at 12:38 PM, Stefan Sperling <st...@elego.de> wrote:
>>> On Wed, Oct 29, 2008 at 11:58:45AM -0400, Mark Phippard wrote:
>>>> Using current trunk. I am doing some basic testing so I can figure
>>>> out JavaHL changes to make around the status/info reporting etc.
>>>>
>>>> I renamed a file and committed it.
>>> So you renamed ColorManager.java to MyColorManager.java, is it?
>>
>> Yes.
>>
>>>> In second WC, I made some edits to file and then did update. This
>>>> reported the tree conflict. I saw stuff like this:
>>>>
>>>> $ svn st
>>>> M C trunk/src/com/acme/ui/editors/ColorManager.java
>>>> M trunk/src/com/acme/ui/editors/MyColorManager.java
>>>>
[...]
>>>> In my example, the edits I made to this file were
>>>> actually automatically transferred to the new file ... Cool!.
>>> Wow, I wish I knew why :)
>
> Yeah, Steve, explain :)
See update_tests.py 37-40 ("update should make use of copyfrom
args").
In the second WC, if the new file is added before the old file is
deleted, then we use the old file as the source instead of asking
the repo. The magic is in add_file_with_history() and in
locate_copyfrom(). Blame tells me the magician was sussman, about
a year ago.
If you include both files in a single commit, you tend not to
get the magic. For instance, in our tree conflict tests it
doesn't happen.
HTH,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Stephen Butler <sb...@elego.de>.
Quoting Mark Phippard <ma...@gmail.com>:
> On Fri, Oct 31, 2008 at 1:08 AM, Stephen Butler <sb...@elego.de> wrote:
>> Quoting Mark Phippard <ma...@gmail.com>:
>> Here's a funny message that means "out of date". But running
>> svn update again will just re-raise the tree conflict!
>> Carrying out the deletion in the first place would solve
>> the dilemma.
>
> Just so you know, I was just running some of those commands to show
> that there are no commands you can do to get out of the state.
>
> Another problem, although I think it is related to the core issue is
> that there is no way to fix your working copy. For example, if I
> revert my whole working copy, when I try to run update again at some
> point I get this:
>
> Working copy is corrupt
> svn: Attempt to add tree conflict that already exists
> svn: subversion/libsvn_wc/tree_conflicts.c:518: (apr_err=155016)
>
> So Revert is not removing the tree conflicts from the working copy.
Hi Mark,
I have a simple patch to re-enable the deletion of tree conflict
victims by update/switch.
I believe this will prevent the user from entering the unfixable
wc-state you discovered. Thanks for the recipe.
I'll add the necessary changes to svn revert/resolved so that they
act on t.c. victims directly, like the other commands now do. That
will take care of the recursive-revert bug you mentioned.
Regards,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: Tree conflict bug?
Posted by Neels J Hofmeyr <ne...@elego.de>.
Julian Foad wrote:
> Steve, you just committed a change to make "update" carry out a deletion
> while raising a tree conflict. I don't get why that's what we need. Is
> that in keeping with a plan or is it just addressing the current
> situation? I thought the plan was to skip any updating when we raise a
> tree conflict,
[...]
What he said.
I think it's unnecessarily complicating the situation. I also don't
understand how it helps, once the revert is fixed.
~Neels
Re: Tree conflict bug?
Posted by Stephen Butler <sb...@elego.de>.
Quoting "Neels J. Hofmeyr" <ne...@elego.de>:
>
>
> Stephen Butler wrote:
>> Quoting Julian Foad <ju...@btopenworld.com>:
>>> Steve, you just committed a change to make "update" carry out a deletion
>>> while raising a tree conflict. I don't get why that's what we need. Is
>>> that in keeping with a plan or is it just addressing the current
>>> situation? I thought the plan was to skip any updating when we raise a
>>> tree conflict, but I'm afraid I've rather lost track of the grand plan
>>> through concentrating on the individual parts of it.
>>
>> That was the plan. Maybe we can actually do it that way. But our
>> current tree conflict implementation (before r33983, the change you
>> mention) can easily put the user in a situation where there is a
>> tree conflict with no escape:
>>
>> 1. The working copy has a modified file that update wants to delete.
>>
>> 2. We flag a tree conflict during update and skip the deletion.
>>
>> 3. The user can't commit, because the file doesn't exist in the
>> repository anymore.
>>
>> 4. The user can't svn remove the file. With --force, their mods
>> will be lost. Anyway, that would lead to another kind of tree
>> conflict.
>>
>> 5. The user can't svn add the file to reinstate it, because it's
>> still under version control.
>>
>> 6. The user can't svn delete the file to accept the incoming
>> deletion, because commit says the working copy is out of date.
>
> Hey, (4.) svn remove and (6.) svn delete are the same thing.
Oops!
>
>>
>> 7. The user can update, but it doesn't solve the out-of-date
>> problem in commit.
>
> Still, it is unacceptable to remove a file that may have local
> modificationse.
At the moment, the file foo in Julian's tree-conflict-bug.sh is left
in place, unversioned, because it has local mods.
The change I made in r33983 is really just a stopgap, necessary
because we essentially broke the trunk. It would be nicer to mark
the tree conflict without removing the to-be-deleted file from
version control.
>
> Two ideas:
>
> a) How about revert or resolved?
> I think this would be best solved by one of these. Since resolved should be
> called when the conflict has been sorted out (resolved), I guess revert
> would be the way to go.
>
> (this is fiction:)
> $ svn status
> M file_incoming_delete
> $ svn up
> C file_incoming_delete
> $ ls
> file_incoming_delete
> $ svn revert file_incoming_delete
> D file_incoming_delete
> $ ls
> <no file_incoming_delete>
> $ svn ci
> Committed revision N+1.
I believe there is nothing to commit here. By running revert, the
user has asked svn to finish the update for this file, i.e., to get
rid of it.
I can't help feeling that revert should go "back in time", to the
BASE of the non-updated item, and not forward to the target revision
of the update. We'll have to squirrel away the target revision
somewhere, if we want revert to update to it.
>
>
> b) How about delete/add --resolve?
>
> (this is fiction:)
> $ svn status
> M file_incoming_delete
> $ svn up
> C file_incoming_delete
> $ ls
> file_incoming_delete
> $ svn rm file_incoming_delete
> <Cannot remove file_incoming_delete>
> To resolve a tree-conflict, use `svn rm --resolve'.
> <this message shows only in presence of a tree-conflict>
> $ svn rm --resolve file_incoming_delete
> D file_incoming_delete
> $ ls
> <no file_incoming_delete>
> $ svn ci
> Committed revision N+1.
Again, commit has nothing to do here after finishing the update.
>
> (this is fiction:)
> $ svn status
> M file_incoming_delete
> $ svn up
> C file_incoming_delete
> $ ls
> file_incoming_delete
> $ svn add file_incoming_delete
> <Cannot add file_incoming_delete>
> To resolve a tree-conflict, use `svn add --resolve'.
> <this message shows only in presence of a tree-conflict>
> $ svn add --resolve file_incoming_delete
> A file_incoming_delete
> $ ls
> file_incoming_delete
> $ svn ci
> Committed revision N+1.
>
> Isn't one or both of them worth implementing instead of the current fix? Or
> what is it you're saying, Steve? ;)
I like them both, in general.
Maybe we should first fix svn resolve to handle tree conflicts.
'svn add --resolve' sounds like 'svn resolve --accept theirs-full'
and 'svn del --resolve' sounds like 'svn resolve --accept mine-full',
in this case.
We may want the --resolve option for add/del anyway, even if it
duplicates svn resolve's behavior.
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Stephen Butler wrote:
> Quoting Julian Foad <ju...@btopenworld.com>:
>> Steve, you just committed a change to make "update" carry out a deletion
>> while raising a tree conflict. I don't get why that's what we need. Is
>> that in keeping with a plan or is it just addressing the current
>> situation? I thought the plan was to skip any updating when we raise a
>> tree conflict, but I'm afraid I've rather lost track of the grand plan
>> through concentrating on the individual parts of it.
>
> That was the plan. Maybe we can actually do it that way. But our
> current tree conflict implementation (before r33983, the change you
> mention) can easily put the user in a situation where there is a
> tree conflict with no escape:
>
> 1. The working copy has a modified file that update wants to delete.
>
> 2. We flag a tree conflict during update and skip the deletion.
>
> 3. The user can't commit, because the file doesn't exist in the
> repository anymore.
>
> 4. The user can't svn remove the file. With --force, their mods
> will be lost. Anyway, that would lead to another kind of tree
> conflict.
>
> 5. The user can't svn add the file to reinstate it, because it's
> still under version control.
>
> 6. The user can't svn delete the file to accept the incoming
> deletion, because commit says the working copy is out of date.
Hey, (4.) svn remove and (6.) svn delete are the same thing.
>
> 7. The user can update, but it doesn't solve the out-of-date
> problem in commit.
Still, it is unacceptable to remove a file that may have local modifications.
Two ideas:
a) How about revert or resolved?
I think this would be best solved by one of these. Since resolved should be
called when the conflict has been sorted out (resolved), I guess revert
would be the way to go.
(this is fiction:)
$ svn status
M file_incoming_delete
$ svn up
C file_incoming_delete
$ ls
file_incoming_delete
$ svn revert file_incoming_delete
D file_incoming_delete
$ ls
<no file_incoming_delete>
$ svn ci
Committed revision N+1.
b) How about delete/add --resolve?
(this is fiction:)
$ svn status
M file_incoming_delete
$ svn up
C file_incoming_delete
$ ls
file_incoming_delete
$ svn rm file_incoming_delete
<Cannot remove file_incoming_delete>
To resolve a tree-conflict, use `svn rm --resolve'.
<this message shows only in presence of a tree-conflict>
$ svn rm --resolve file_incoming_delete
D file_incoming_delete
$ ls
<no file_incoming_delete>
$ svn ci
Committed revision N+1.
(this is fiction:)
$ svn status
M file_incoming_delete
$ svn up
C file_incoming_delete
$ ls
file_incoming_delete
$ svn add file_incoming_delete
<Cannot add file_incoming_delete>
To resolve a tree-conflict, use `svn add --resolve'.
<this message shows only in presence of a tree-conflict>
$ svn add --resolve file_incoming_delete
A file_incoming_delete
$ ls
file_incoming_delete
$ svn ci
Committed revision N+1.
Isn't one or both of them worth implementing instead of the current fix? Or
what is it you're saying, Steve? ;)
~Neels
Re: Tree conflict bug?
Posted by Julian Foad <ju...@btopenworld.com>.
On Sat, 2008-11-01 at 18:44 +0100, Stephen Butler wrote:
> Quoting Julian Foad <ju...@btopenworld.com>:
>
> > So, what have we found?
> >
> > * "revert" acts on the parent dir, but needs to act on a victim instead
> > for consistency.
> > - I'm fixing that.
> >
> > * "revert -R" fails to revert the whole WC,
> > - I haven't yet reproduced that.
> >
> > * Commit fails with poor error message "File not found: transaction
> > '2-3', path '/foo'" instead of "Out of date".
> > - To be investigated.
>
> Fixed in r33994. I had an old patch lying around from back in February,
> when I was hacking on the double-delete branch (since merged to trunk).
> Just needed to intercept those funky error messages in the client and
> wrap them in a more friendly "out of date" error.
Excellent. Thanks, Steve.
> > * Revert then update leads to "WC is corrupt... Attempt to add tree
> > conflict that already exists". That's possibly a bad error message: I
> > think it might mean that there's a bug in the code that's trying to
> > raise a new conflict, not that the WC is corrupt.
> > - We must change the error message to admit that it might well be a
> > bug.
> > - The cause is to be investigated.
>
> In most of the update callbacks, we don't yet check for an existing
> tree (or other) conflict before creating a fresh tree conflict.
Yes. That, I believe, is something we must fix.
> > I've started tackling the "revert must act on a victim" now, but I'm not
> > sure that is the most urgent issue, since as far as I can tell it does
> > actually work (clear tree conflict indications) if you give it the
> > parent path (or recursive).
> >
> > Steve, you just committed a change to make "update" carry out a deletion
> > while raising a tree conflict. I don't get why that's what we need. Is
> > that in keeping with a plan or is it just addressing the current
> > situation? I thought the plan was to skip any updating when we raise a
> > tree conflict, but I'm afraid I've rather lost track of the grand plan
> > through concentrating on the individual parts of it.
>
> That was the plan. Maybe we can actually do it that way. But our
> current tree conflict implementation (before r33983, the change you
> mention) can easily put the user in a situation where there is a
> tree conflict with no escape:
>
> 1. The working copy has a modified file that update wants to delete.
>
> 2. We flag a tree conflict during update and skip the deletion.
>
> 3. The user can't commit, because the file doesn't exist in the
> repository anymore.
>
> 4. The user can't svn remove the file. With --force, their mods
> will be lost. Anyway, that would lead to another kind of tree
> conflict.
>
> 5. The user can't svn add the file to reinstate it, because it's
> still under version control.
>
> 6. The user can't svn delete the file to accept the incoming
> deletion, because commit says the working copy is out of date.
>
> 7. The user can update, but it doesn't solve the out-of-date
> problem in commit.
>
> Maybe there's a clever way to work around this. I couldn't
> think of one, so I sacrificed the "skip everything" design
> principle. Allowing update to delete tree-conflicted trees
> is a very simple code change, and it solves all of the
> problems listed above. Commit (#3) is a no-op, and .
If it solves all of the problems there, there's got to be something
right!
> As I mentioned in my first reply to Mark, from the earliest
> powerpoints (issue 2282) that inspired our tree conflict effort,
> we always jumped from tree conflict detection to svn resolved
> & svn commit with a bit of hand-waving.
>
> Anyway, since r33983 I can run your tree-conflict-bug.sh script
> and it all works fine.
Thanks. At least that seems like a better state of usability from which
we can proceed.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Stephen Butler <sb...@elego.de>.
Quoting Julian Foad <ju...@btopenworld.com>:
> So, what have we found?
>
> * "revert" acts on the parent dir, but needs to act on a victim instead
> for consistency.
> - I'm fixing that.
>
> * "revert -R" fails to revert the whole WC,
> - I haven't yet reproduced that.
>
> * Commit fails with poor error message "File not found: transaction
> '2-3', path '/foo'" instead of "Out of date".
> - To be investigated.
Fixed in r33994. I had an old patch lying around from back in February,
when I was hacking on the double-delete branch (since merged to trunk).
Just needed to intercept those funky error messages in the client and
wrap them in a more friendly "out of date" error.
>
> * Revert then update leads to "WC is corrupt... Attempt to add tree
> conflict that already exists". That's possibly a bad error message: I
> think it might mean that there's a bug in the code that's trying to
> raise a new conflict, not that the WC is corrupt.
> - We must change the error message to admit that it might well be a
> bug.
> - The cause is to be investigated.
In most of the update callbacks, we don't yet check for an existing
tree (or other) conflict before creating a fresh tree conflict.
>
>
> I've started tackling the "revert must act on a victim" now, but I'm not
> sure that is the most urgent issue, since as far as I can tell it does
> actually work (clear tree conflict indications) if you give it the
> parent path (or recursive).
>
> Steve, you just committed a change to make "update" carry out a deletion
> while raising a tree conflict. I don't get why that's what we need. Is
> that in keeping with a plan or is it just addressing the current
> situation? I thought the plan was to skip any updating when we raise a
> tree conflict, but I'm afraid I've rather lost track of the grand plan
> through concentrating on the individual parts of it.
That was the plan. Maybe we can actually do it that way. But our
current tree conflict implementation (before r33983, the change you
mention) can easily put the user in a situation where there is a
tree conflict with no escape:
1. The working copy has a modified file that update wants to delete.
2. We flag a tree conflict during update and skip the deletion.
3. The user can't commit, because the file doesn't exist in the
repository anymore.
4. The user can't svn remove the file. With --force, their mods
will be lost. Anyway, that would lead to another kind of tree
conflict.
5. The user can't svn add the file to reinstate it, because it's
still under version control.
6. The user can't svn delete the file to accept the incoming
deletion, because commit says the working copy is out of date.
7. The user can update, but it doesn't solve the out-of-date
problem in commit.
Maybe there's a clever way to work around this. I couldn't
think of one, so I sacrificed the "skip everything" design
principle. Allowing update to delete tree-conflicted trees
is a very simple code change, and it solves all of the
problems listed above. Commit (#3) is a no-op, and .
As I mentioned in my first reply to Mark, from the earliest
powerpoints (issue 2282) that inspired our tree conflict effort,
we always jumped from tree conflict detection to svn resolved
& svn commit with a bit of hand-waving.
Anyway, since r33983 I can run your tree-conflict-bug.sh script
and it all works fine.
Regards,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Julian Foad <ju...@btopenworld.com>.
So, what have we found?
* "revert" acts on the parent dir, but needs to act on a victim instead
for consistency.
- I'm fixing that.
* "revert -R" fails to revert the whole WC,
- I haven't yet reproduced that.
* Commit fails with poor error message "File not found: transaction
'2-3', path '/foo'" instead of "Out of date".
- To be investigated.
* Revert then update leads to "WC is corrupt... Attempt to add tree
conflict that already exists". That's possibly a bad error message: I
think it might mean that there's a bug in the code that's trying to
raise a new conflict, not that the WC is corrupt.
- We must change the error message to admit that it might well be a
bug.
- The cause is to be investigated.
I've started tackling the "revert must act on a victim" now, but I'm not
sure that is the most urgent issue, since as far as I can tell it does
actually work (clear tree conflict indications) if you give it the
parent path (or recursive).
Steve, you just committed a change to make "update" carry out a deletion
while raising a tree conflict. I don't get why that's what we need. Is
that in keeping with a plan or is it just addressing the current
situation? I thought the plan was to skip any updating when we raise a
tree conflict, but I'm afraid I've rather lost track of the grand plan
through concentrating on the individual parts of it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Stephen Butler <sb...@elego.de>.
Quoting Julian Foad <ju...@btopenworld.com>:
>>
>> So Revert is not removing the tree conflicts from the working copy.
>
> Revert! Argh, you're right. I'll fix it.
>
> (Attaching a runnable version of your script.)
>
> - Julian
I'll commit my patch to update/switch as soon as make check passes.
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Julian Foad <ju...@btopenworld.com>.
On Fri, 2008-10-31 at 09:57 -0400, Mark Phippard wrote:
> On Fri, Oct 31, 2008 at 1:08 AM, Stephen Butler <sb...@elego.de> wrote:
> > Quoting Mark Phippard <ma...@gmail.com>:
>
> >> $ svn st wc2
> >> M wc2/foo
> >> $ svn up wc2
> >> C wc2/foo
> >> A wc2/bar
> >> Updated to revision 2.
> >> Summary of conflicts:
> >> Tree conflicts: 1
> >> $ svn st wc2
> >> M C wc2/foo
> >> $ svn resolved wc2
> >> Resolved conflicted state of 'wc2'
> >> $ svn st wc2
> >> M wc2/foo
> >
> >> svn: File not found: transaction '2-2', path '/foo'
> >> $ svn add wc2/foo
> >> svn: warning: 'wc2/foo' is already under version control
> >> $ svn st wc2
> >> M wc2/foo
> >> $ svn add --force wc2/foo
> >> $ svn st wc2
> >> M wc2/foo
> >> $ svn ci -m "Cannot checkin" wc2Sending wc2/foo
> >> subversion/libsvn_client/commit.c:864: (apr_err=160013)
> >> svn: Commit failed (details follow):
> >> subversion/libsvn_fs_fs/tree.c:661: (apr_err=160013)
> >> svn: File not found: transaction '2-3', path '/foo'
> >
> > Here's a funny message that means "out of date". But running
> > svn update again will just re-raise the tree conflict!
> > Carrying out the deletion in the first place would solve
> > the dilemma.
>
> Just so you know, I was just running some of those commands to show
> that there are no commands you can do to get out of the state.
>
> Another problem, although I think it is related to the core issue is
> that there is no way to fix your working copy. For example, if I
> revert my whole working copy, when I try to run update again at some
> point I get this:
>
> Working copy is corrupt
> svn: Attempt to add tree conflict that already exists
> svn: subversion/libsvn_wc/tree_conflicts.c:518: (apr_err=155016)
>
> So Revert is not removing the tree conflicts from the working copy.
Revert! Argh, you're right. I'll fix it.
(Attaching a runnable version of your script.)
- Julian
Re: Tree conflict bug?
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Oct 31, 2008 at 1:08 AM, Stephen Butler <sb...@elego.de> wrote:
> Quoting Mark Phippard <ma...@gmail.com>:
>> $ svn st wc2
>> M wc2/foo
>> $ svn up wc2
>> C wc2/foo
>> A wc2/bar
>> Updated to revision 2.
>> Summary of conflicts:
>> Tree conflicts: 1
>> $ svn st wc2
>> M C wc2/foo
>> $ svn resolved wc2
>> Resolved conflicted state of 'wc2'
>> $ svn st wc2
>> M wc2/foo
>
>> svn: File not found: transaction '2-2', path '/foo'
>> $ svn add wc2/foo
>> svn: warning: 'wc2/foo' is already under version control
>> $ svn st wc2
>> M wc2/foo
>> $ svn add --force wc2/foo
>> $ svn st wc2
>> M wc2/foo
>> $ svn ci -m "Cannot checkin" wc2Sending wc2/foo
>> subversion/libsvn_client/commit.c:864: (apr_err=160013)
>> svn: Commit failed (details follow):
>> subversion/libsvn_fs_fs/tree.c:661: (apr_err=160013)
>> svn: File not found: transaction '2-3', path '/foo'
>
> Here's a funny message that means "out of date". But running
> svn update again will just re-raise the tree conflict!
> Carrying out the deletion in the first place would solve
> the dilemma.
Just so you know, I was just running some of those commands to show
that there are no commands you can do to get out of the state.
Another problem, although I think it is related to the core issue is
that there is no way to fix your working copy. For example, if I
revert my whole working copy, when I try to run update again at some
point I get this:
Working copy is corrupt
svn: Attempt to add tree conflict that already exists
svn: subversion/libsvn_wc/tree_conflicts.c:518: (apr_err=155016)
So Revert is not removing the tree conflicts from the working copy.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Stephen Butler <sb...@elego.de>.
Quoting Mark Phippard <ma...@gmail.com>:
> On Thu, Oct 30, 2008 at 2:04 AM, Neels J Hofmeyr <ne...@elego.de> wrote:
>>
>>
>> Mark Phippard wrote:
>>> For a user to want or expect that behavior would seem that they would
>>> have to just ignore what an update command does. If I run update does
>>> it update or not? If it does, then the file ought to reflect the
>>> state of the repository -- unversioned. Of course perhaps we need to
>>> invent a new "state" for this scenario, but if we have to choose from
>>> our existing states I think unversioned is the one that reflects the
>>> reality of the situation. It also puts the working copy in the best
>>> place to resolve the conflict as the user can run svn add or "rm" to
>>> put the WC into the desired state. In this scenario, it probably
>>> makes sense for the parent folder to be in the tree conflict state?
Hi Mark,
Out of curiousity, I had a look at our initial problem statement
in /notes/tree-conflicts/use-cases.txt. Use case #2 is similar
to your transcript. We display something equivalent to
C foo.c
A bar.c
during svn update that tries to delete a foo.c that has local
mods. So far, so good. But then, in our diagram, foo.c
magically disappears somewhere near svn resolved, right where
you run into trouble with svn add and svn rm.
For what it's worth, our tests (currently) check the results
of the individual commands, but not any use cases from start to
finish. :-(
> $ svn st wc2
> M wc2/foo
> $ svn up wc2
> C wc2/foo
> A wc2/bar
> Updated to revision 2.
> Summary of conflicts:
> Tree conflicts: 1
> $ svn st wc2
> M C wc2/foo
> $ svn resolved wc2
> Resolved conflicted state of 'wc2'
> $ svn st wc2
> M wc2/foo
> svn: File not found: transaction '2-2', path '/foo'
> $ svn add wc2/foo
> svn: warning: 'wc2/foo' is already under version control
> $ svn st wc2
> M wc2/foo
> $ svn add --force wc2/foo
> $ svn st wc2
> M wc2/foo
> $ svn ci -m "Cannot checkin" wc2Sending wc2/foo
> subversion/libsvn_client/commit.c:864: (apr_err=160013)
> svn: Commit failed (details follow):
> subversion/libsvn_fs_fs/tree.c:661: (apr_err=160013)
> svn: File not found: transaction '2-3', path '/foo'
Here's a funny message that means "out of date". But running
svn update again will just re-raise the tree conflict!
Carrying out the deletion in the first place would solve
the dilemma.
I think skipping parts of an update is OK where the update
wants to add or edit something. For a directory, an "edit"
can include deletion of descendants. We can still skip
those deletions.
We've already added a sort of "limbo" state for tree conflict
victims that are unversioned or simply do not exist. In svn
status they appear as
? C foo-unversioned.c
! C foo-really-gone.c
So maybe there's a way forward for the update case. I'll
ponder merge over breakfast.
Thanks for the feedback!
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Oct 30, 2008 at 2:04 AM, Neels J Hofmeyr <ne...@elego.de> wrote:
>
>
> Mark Phippard wrote:
>> On Wed, Oct 29, 2008 at 9:38 PM, Neels J. Hofmeyr <ne...@elego.de> wrote:
>>> Just re-iterating: When you run Revert, I'd expect it to become the reverted
>>> state before the tree-conflict, i.e. the old base without local mods. Which
>>> is kind of not what sentient users might expect at all.
>>
>> For a user to want or expect that behavior would seem that they would
>> have to just ignore what an update command does. If I run update does
>> it update or not? If it does, then the file ought to reflect the
>> state of the repository -- unversioned. Of course perhaps we need to
>> invent a new "state" for this scenario, but if we have to choose from
>> our existing states I think unversioned is the one that reflects the
>> reality of the situation. It also puts the working copy in the best
>> place to resolve the conflict as the user can run svn add or "rm" to
>> put the WC into the desired state. In this scenario, it probably
>> makes sense for the parent folder to be in the tree conflict state?
>>
>
> A quick response on this:
>
> You are right, the behaviour you are describing is definitely wrong. Do you
> still have the commands to reproduce the error?
So here is a transcript I just made.
$ svn --version
svn, version 1.6.0 (dev build)
compiled Oct 30 2008, 14:36:18
Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
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
$ cd ~
$ mkdir tree-conflicts
$ cd tree-conflicts/
$ svnadmin create repos
$ svn co file://`pwd`/repos wc1
Checked out revision 0.
$ echo "File 123" > wc1/foo
$ svn add wc1/foo
A wc1/foo
$ svn ci -m "Add foo" wc1/
Adding wc1/foo
Transmitting file data .
Committed revision 1.
$ svn co file://`pwd`/repos wc2
A wc2/foo
Checked out revision 1.
$ svn up wc1
At revision 1.
svn$ svn move wc1/foo wc1/bar
A wc1/bar
D wc1/foo
$ svn ci -m "Rename foo to bar" wc1
Adding wc1/bar
Deleting wc1/foo
Committed revision 2.
$ echo "Edit foo" >> wc2/foo
$ svn st wc2
M wc2/foo
$ svn up wc2
C wc2/foo
A wc2/bar
Updated to revision 2.
Summary of conflicts:
Tree conflicts: 1
$ svn st wc2
M C wc2/foo
$ svn resolved wc2
Resolved conflicted state of 'wc2'
$ svn st wc2
M wc2/foo
$ svn ci -m "Cannot checkin" wc2Sending wc2/foo
subversion/libsvn_client/commit.c:864: (apr_err=160013)
svn: Commit failed (details follow):
subversion/libsvn_fs_fs/tree.c:661: (apr_err=160013)
svn: File not found: transaction '2-2', path '/foo'
$ svn add wc2/foo
svn: warning: 'wc2/foo' is already under version control
$ svn st wc2
M wc2/foo
$ svn add --force wc2/foo
$ svn st wc2
M wc2/foo
$ svn ci -m "Cannot checkin" wc2Sending wc2/foo
subversion/libsvn_client/commit.c:864: (apr_err=160013)
svn: Commit failed (details follow):
subversion/libsvn_fs_fs/tree.c:661: (apr_err=160013)
svn: File not found: transaction '2-3', path '/foo'
$ svn rm wc2/foo
subversion/svn/util.c:860: (apr_err=195006)
svn: Use --force to override this restriction
subversion/libsvn_client/delete.c:65: (apr_err=195006)
svn: 'wc2/foo' has local modifications
$ svn revert wc2/foo
Reverted 'wc2/foo'
$ svn info wc2/foo
Path: wc2/foo
Name: foo
URL: file:///Users/mphippard/tree-conflicts/repos/foo
Repository Root: file:///Users/mphippard/tree-conflicts/repos
Repository UUID: 67048387-9e2d-479b-8f38-28271a7f8fe3
Revision: 2
Node Kind: file
Schedule: normal
Last Changed Author: mphippard
Last Changed Rev: 1
Last Changed Date: 2008-10-30 14:40:12 -0400 (Thu, 30 Oct 2008)
Text Last Updated: 2008-10-30 14:44:44 -0400 (Thu, 30 Oct 2008)
Checksum: bc6defbfcce1638222800efc165b204c
$ svn rm wc2/foo
D wc2/foo
$ svn ci -m "Cannot delete" wc2
Deleting wc2/foo
subversion/libsvn_client/commit.c:864: (apr_err=160028)
svn: Commit failed (details follow):
subversion/libsvn_repos/commit.c:124: (apr_err=160028)
svn: File or directory '/foo' is out of date
$ svn up wc2
At revision 2.
$ svn ci -m "Cannot delete" wc2
Deleting wc2/foo
subversion/libsvn_client/commit.c:864: (apr_err=160028)
svn: Commit failed (details follow):
subversion/libsvn_repos/commit.c:124: (apr_err=160028)
svn: File or directory '/foo' is out of date
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Neels J Hofmeyr <ne...@elego.de>.
Mark Phippard wrote:
> On Wed, Oct 29, 2008 at 9:38 PM, Neels J. Hofmeyr <ne...@elego.de> wrote:
>> Just re-iterating: When you run Revert, I'd expect it to become the reverted
>> state before the tree-conflict, i.e. the old base without local mods. Which
>> is kind of not what sentient users might expect at all.
>
> For a user to want or expect that behavior would seem that they would
> have to just ignore what an update command does. If I run update does
> it update or not? If it does, then the file ought to reflect the
> state of the repository -- unversioned. Of course perhaps we need to
> invent a new "state" for this scenario, but if we have to choose from
> our existing states I think unversioned is the one that reflects the
> reality of the situation. It also puts the working copy in the best
> place to resolve the conflict as the user can run svn add or "rm" to
> put the WC into the desired state. In this scenario, it probably
> makes sense for the parent folder to be in the tree conflict state?
>
A quick response on this:
You are right, the behaviour you are describing is definitely wrong. Do you
still have the commands to reproduce the error?
For fixing it, I'd like to note: It feels wrong to me to ever unversion a
file that has local mods. Instead of creating a pitfall where people lose
their local changes when they forget to re-add a file that was perfectly
versioned Since Forever, I would prefer keeping the file versioned and
requiring an `svn rm' by the user if she doesn't want it anymore.
An exception would be the `move' case, where we successfully auto-moved the
local mods to the new file, if we are ever going to do that. Then I'd
happily agree with unversioning and removing the old file automatically. But
in all current tree-conflict cases I can think of, I emphatically wouldn't.
~Neels
Re: Tree conflict bug?
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Oct 29, 2008 at 9:38 PM, Neels J. Hofmeyr <ne...@elego.de> wrote:
>> Well there are two issues. The repository has already decided this
>> file does not exist any more. So if I want the file, I will have to
>> svn add it. But the current status of the file in the WC would make
>> this hard to know. In my case, I decided that I want my changes in
>> the new file, so I want it go away.
>
> All the while that I am fixing tree-conflicts issues, I am thinking
> differently than that. I see it so that my working copy is at first hooked
> to its base. So then I run `svn update', pulling in changes, and the working
> copy's base is adapted. But when a tree-conflict occurs, the single safe
> thing to do is Nothing At All. So those nodes that encounter tree-conflicts
> remain untouched, their base remains the old one before the update.
>
> Your case, specifically: You pulled in a delete on a locally modified file.
> You get a tree-conflict. In my understanding, the working copy should still
> have a locally modified, versioned file, as in the base before the update.
> So I don't see it as "the repository has decided that this file should be
> gone", but I see it like "at the point in the repository history we are
> still at, which may be a past revision, the file is still there".
I am not sure I agree, but ultimately it just depends on what "tools"
we are going to give the user. For example, I'd be OK with using
revert to go back to the normal state if I could then run svn update
to have it be deleted. This does not happen though as the WC seems to
think it is up to date.
I think the current behavior is wrong because there are only two
things that a user can want to do here. They either want the file to
remain, in which case they are going to need to add the file again, or
they want the file gone. Since the WC thinks this is a normal
versioned file you cannot do either. You are basically just stuck in
"no-mans" land.
> Now, IIUC, the "special" behaviour where the local modifications are
> actually moved to the new file is probably clashing with the tree-conflicts
> guideline. Some other code moves the local mods somewhere else, but
> tree-conflicts code is in tendency desperate to do Nothing At All. So you
> got, am I right, a file whose local mods went where they should (to the move
> destination), but the original file was left hanging there, versioned and all?
>
> It needs to be un-clashed.
Actually I do not think the fact that my changes were copied to the
new file are all that relevant. It was nice that it happened but it
was just "luck" that I picked an example where this happened. There
is no need to focus on this as I do not believe it added anything to
the process that we need to take special account of. Maybe with the
possible exception that I suppose this is a case where we could
theoretically have "auto-resolved" the conflict and not even raised
it. I know people feel strongly on both sides of that issue and we
can cross that bridge when we have more situations where we are
capable of auto-resolving the conflicts.
>> I am OK with that (although I have not yet figured out how to do it.
>> I do think we need to make revert pick some default "resolved"
>> equivalent. Either that or do not let revert run at all.
>
> I would expect "revert" to bring the file in question back to the base
> *before* the update that encountered a conflict on it. Let's unroll this a
> little:
>
> Wow, another box of complexity opens up on me: Text and prop conflicts are
> handled so that the modifications are somehow pulled in, the base is now the
> new one (that was updated to) everywhere, and there are local mods that show
> both sides of a (plain) conflict. Am I right?
> In contrast, tree-conflicts code is in my sense *preventing the update*. But
> it does that only for those files that are tree-conflicted. I don't see how
> we can change that, because you can't just pull in changes in the presence
> of tree-conflicts: in many cases there simply is no place to put both sides
> of a conflict at. Plus, I wouldn't know how to present both sides of a
> tree-conflict in the form of local mods on the working copy.
>
> Ok, so tree-conflicts do need to skip the update. Hence, the base stays the
> old one, hence revert will restore the old base.
>
> Is it tolerable that tree-conflicts cause the working copy to be at
> different bases at different nodes? Should the whole update be prevented
> completely? My immediate intuition says: no way. I want to see what the new
> state is, so that I can mend my conflicts into it.
>
> So I guess that's it: in the presence of tree-conflicts, there *will* be two
> different bases scattered around the working copy: conflicted nodes are at
> the old base, non-conflicted ones were updated as usual.
>
> This might just be a concept that many people may find very difficult to
> grasp; that the update is finished as far as most nodes are concerned, but
> was prevented to happen on the tree-conflicted nodes. It's half an update.
>
> Please tell me I'm wrong...
What do you mean by "two different bases"? It sounds like you are
just describing a mixed revision working copy. The bottom line is
that the file is gone from the repository -- whether the user likes it
or not. I do not think we are doing the user any favors by pretending
the file is still versioned when it isn't. If we are going to do
this, we ought to at least have the entries file of the parent folder
understand that it has the older revision of this file so that I can
do a revert and update to delete it.
>> Well, since I know the file does not exist in the repository any more.
>> The only valid states I can see for this file would be Scheduled add
>> or Unversioned. Since I ran Revert, I'd expect it to become
>> unversioned.
>
> Just re-iterating: When you run Revert, I'd expect it to become the reverted
> state before the tree-conflict, i.e. the old base without local mods. Which
> is kind of not what sentient users might expect at all.
For a user to want or expect that behavior would seem that they would
have to just ignore what an update command does. If I run update does
it update or not? If it does, then the file ought to reflect the
state of the repository -- unversioned. Of course perhaps we need to
invent a new "state" for this scenario, but if we have to choose from
our existing states I think unversioned is the one that reflects the
reality of the situation. It also puts the working copy in the best
place to resolve the conflict as the user can run svn add or "rm" to
put the WC into the desired state. In this scenario, it probably
makes sense for the parent folder to be in the tree conflict state?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Mark Phippard wrote:
> On Wed, Oct 29, 2008 at 12:38 PM, Stefan Sperling <st...@elego.de> wrote:
>> On Wed, Oct 29, 2008 at 11:58:45AM -0400, Mark Phippard wrote:
>>> Using current trunk. I am doing some basic testing so I can figure
>>> out JavaHL changes to make around the status/info reporting etc.
>>>
>>> I renamed a file and committed it.
>> So you renamed ColorManager.java to MyColorManager.java, is it?
>
> Yes.
>
>>> In second WC, I made some edits to file and then did update. This
>>> reported the tree conflict. I saw stuff like this:
>>>
>>> $ svn st
>>> M C trunk/src/com/acme/ui/editors/ColorManager.java
>>> M trunk/src/com/acme/ui/editors/MyColorManager.java
>>>
[...]
> Well there are two issues. The repository has already decided this
> file does not exist any more. So if I want the file, I will have to
> svn add it. But the current status of the file in the WC would make
> this hard to know. In my case, I decided that I want my changes in
> the new file, so I want it go away.
All the while that I am fixing tree-conflicts issues, I am thinking
differently than that. I see it so that my working copy is at first hooked
to its base. So then I run `svn update', pulling in changes, and the working
copy's base is adapted. But when a tree-conflict occurs, the single safe
thing to do is Nothing At All. So those nodes that encounter tree-conflicts
remain untouched, their base remains the old one before the update.
Your case, specifically: You pulled in a delete on a locally modified file.
You get a tree-conflict. In my understanding, the working copy should still
have a locally modified, versioned file, as in the base before the update.
So I don't see it as "the repository has decided that this file should be
gone", but I see it like "at the point in the repository history we are
still at, which may be a past revision, the file is still there".
Now, IIUC, the "special" behaviour where the local modifications are
actually moved to the new file is probably clashing with the tree-conflicts
guideline. Some other code moves the local mods somewhere else, but
tree-conflicts code is in tendency desperate to do Nothing At All. So you
got, am I right, a file whose local mods went where they should (to the move
destination), but the original file was left hanging there, versioned and all?
It needs to be un-clashed.
>>> In my example, the edits I made to this file were
>>> actually automatically transferred to the new file ... Cool!.
>> Wow, I wish I knew why :)
Yeah, Steve, explain :)
>> Well, the theory goes like this:
>>
>> First, you think about what you want the merge result to be.
>>
>> Then, you make the neccessary changes to your conflicted state
>> to achieve this result and run 'svn resolved' on the tree-conflicted
>> file (currently, you may still have to run 'svn resolved' on the file's
>> parent directory instead of the file itself, I'm not sure whether we've
>> fixed this yet).
>
> I am OK with that (although I have not yet figured out how to do it.
> I do think we need to make revert pick some default "resolved"
> equivalent. Either that or do not let revert run at all.
I would expect "revert" to bring the file in question back to the base
*before* the update that encountered a conflict on it. Let's unroll this a
little:
Wow, another box of complexity opens up on me: Text and prop conflicts are
handled so that the modifications are somehow pulled in, the base is now the
new one (that was updated to) everywhere, and there are local mods that show
both sides of a (plain) conflict. Am I right?
In contrast, tree-conflicts code is in my sense *preventing the update*. But
it does that only for those files that are tree-conflicted. I don't see how
we can change that, because you can't just pull in changes in the presence
of tree-conflicts: in many cases there simply is no place to put both sides
of a conflict at. Plus, I wouldn't know how to present both sides of a
tree-conflict in the form of local mods on the working copy.
Ok, so tree-conflicts do need to skip the update. Hence, the base stays the
old one, hence revert will restore the old base.
Is it tolerable that tree-conflicts cause the working copy to be at
different bases at different nodes? Should the whole update be prevented
completely? My immediate intuition says: no way. I want to see what the new
state is, so that I can mend my conflicts into it.
So I guess that's it: in the presence of tree-conflicts, there *will* be two
different bases scattered around the working copy: conflicted nodes are at
the old base, non-conflicted ones were updated as usual.
This might just be a concept that many people may find very difficult to
grasp; that the update is finished as far as most nodes are concerned, but
was prevented to happen on the tree-conflicted nodes. It's half an update.
Please tell me I'm wrong...
>>
>>> My expectation was that svn revert would leave the file in the WC in
>>> an Unversioned status.
>> Because your initial expectation was also that the file would be
>> unversioned? I'm not saying this expectation was wrong, but we
>> need to agree upon what would be the best thing to do here.
>
> Well, since I know the file does not exist in the repository any more.
> The only valid states I can see for this file would be Scheduled add
> or Unversioned. Since I ran Revert, I'd expect it to become
> unversioned.
Just re-iterating: When you run Revert, I'd expect it to become the reverted
state before the tree-conflict, i.e. the old base without local mods. Which
is kind of not what sentient users might expect at all.
~Neels
Re: Tree conflict bug?
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Oct 29, 2008 at 12:38 PM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Oct 29, 2008 at 11:58:45AM -0400, Mark Phippard wrote:
>> Using current trunk. I am doing some basic testing so I can figure
>> out JavaHL changes to make around the status/info reporting etc.
>>
>> I renamed a file and committed it.
>
> So you renamed ColorManager.java to MyColorManager.java, is it?
Yes.
>> In second WC, I made some edits to file and then did update. This
>> reported the tree conflict. I saw stuff like this:
>>
>> $ svn st
>> M C trunk/src/com/acme/ui/editors/ColorManager.java
>> M trunk/src/com/acme/ui/editors/MyColorManager.java
>>
>> $ svn info trunk/src/com/acme/ui/editors/ColorManager.java
>> Path: trunk/src/com/acme/ui/editors/ColorManager.java
>> Name: ColorManager.java
>> URL: file:///Users/mphippard/repositories/svn-1.6/trunk/src/com/acme/ui/editors/ColorManager.java
>> Repository Root: file:///Users/mphippard/repositories/svn-1.6
>> Repository UUID: a0b8b0e8-12cc-4994-9ac8-95a1682d52c6
>> Revision: 4
>> Node Kind: file
>> Schedule: normal
>> Last Changed Author: mphippard
>> Last Changed Rev: 3
>> Last Changed Date: 2008-10-29 11:44:29 -0400 (Wed, 29 Oct 2008)
>> Text Last Updated: 2008-10-29 11:45:02 -0400 (Wed, 29 Oct 2008)
>> Checksum: df4e1705289bff7b74b555fa1ffc549d
>> Tree conflict:
>> The update attempted to delete 'ColorManager.java'
>> (possibly as part of a rename operation).
>> You have edited 'ColorManager.java' locally.
>>
>>
>> What I am concerned about is that this file "ColorManager.java" still
>> appears to be a versioned file when in fact it no longer exists in the
>> repository.
>
> Right. The question is really whether *you* want it to stay a versioned
> file. Someone decided to rename it, but maybe you really don't want
> that rename to have happened? I guess you would expect having to re-add
> the file at the old location if you wanted to keep it? I think currently
> you're expected to locally delete it if you don't want to keep it (which
> may not make sense, actually...)
Well there are two issues. The repository has already decided this
file does not exist any more. So if I want the file, I will have to
svn add it. But the current status of the file in the WC would make
this hard to know. In my case, I decided that I want my changes in
the new file, so I want it go away.
>> In my example, the edits I made to this file were
>> actually automatically transferred to the new file ... Cool!.
>
> Wow, I wish I knew why :)
>
> AFAIK we have not yet added support for moving changes between moved
> files. Maybe this has got to do with the copy improvements made in 1.5,
> rather than the tree conflict work?
Yes, this is from the 1.5 changes. I think it was just dumb luck that
I picked a scenario where this works.
>> So what
>> do I do here? I guess maybe svn resolve would have done the right
>> thing?
>
> Well, the theory goes like this:
>
> First, you think about what you want the merge result to be.
>
> Then, you make the neccessary changes to your conflicted state
> to achieve this result and run 'svn resolved' on the tree-conflicted
> file (currently, you may still have to run 'svn resolved' on the file's
> parent directory instead of the file itself, I'm not sure whether we've
> fixed this yet).
I am OK with that (although I have not yet figured out how to do it.
I do think we need to make revert pick some default "resolved"
equivalent. Either that or do not let revert run at all.
>> I did svn revert and the bug I am reporting is that this left
>> ColorManager.java in my WC with a status of "Normal". So I edited the
>> file and tried to commit and of course get the message that the file
>> does not exist. So the bug is that the WC was not handled properly.
>
> That sounds like a logic error we made here. Not sure how to handle
> this. We agreed in the past that simply dropping a file from version
> control was unacceptable because changes could get lost when the user
> then forgets to re-add the file. However, now that we are screaming
> "TREE CONFLICT" at the user anyway, we may want to reconsider leaving
> the file unversioned (and saying so in the conflict description).
>
>> My expectation was that svn revert would leave the file in the WC in
>> an Unversioned status.
>
> Because your initial expectation was also that the file would be
> unversioned? I'm not saying this expectation was wrong, but we
> need to agree upon what would be the best thing to do here.
Well, since I know the file does not exist in the repository any more.
The only valid states I can see for this file would be Scheduled add
or Unversioned. Since I ran Revert, I'd expect it to become
unversioned.
> In any case, users ending up in a conflicted state that is not
> resolvable is unacceptable and needs fixing.
Agreed
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflict bug?
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Oct 29, 2008 at 11:58:45AM -0400, Mark Phippard wrote:
> Using current trunk. I am doing some basic testing so I can figure
> out JavaHL changes to make around the status/info reporting etc.
>
> I renamed a file and committed it.
So you renamed ColorManager.java to MyColorManager.java, is it?
> In second WC, I made some edits to file and then did update. This
> reported the tree conflict. I saw stuff like this:
>
> $ svn st
> M C trunk/src/com/acme/ui/editors/ColorManager.java
> M trunk/src/com/acme/ui/editors/MyColorManager.java
>
> $ svn info trunk/src/com/acme/ui/editors/ColorManager.java
> Path: trunk/src/com/acme/ui/editors/ColorManager.java
> Name: ColorManager.java
> URL: file:///Users/mphippard/repositories/svn-1.6/trunk/src/com/acme/ui/editors/ColorManager.java
> Repository Root: file:///Users/mphippard/repositories/svn-1.6
> Repository UUID: a0b8b0e8-12cc-4994-9ac8-95a1682d52c6
> Revision: 4
> Node Kind: file
> Schedule: normal
> Last Changed Author: mphippard
> Last Changed Rev: 3
> Last Changed Date: 2008-10-29 11:44:29 -0400 (Wed, 29 Oct 2008)
> Text Last Updated: 2008-10-29 11:45:02 -0400 (Wed, 29 Oct 2008)
> Checksum: df4e1705289bff7b74b555fa1ffc549d
> Tree conflict:
> The update attempted to delete 'ColorManager.java'
> (possibly as part of a rename operation).
> You have edited 'ColorManager.java' locally.
>
>
> What I am concerned about is that this file "ColorManager.java" still
> appears to be a versioned file when in fact it no longer exists in the
> repository.
Right. The question is really whether *you* want it to stay a versioned
file. Someone decided to rename it, but maybe you really don't want
that rename to have happened? I guess you would expect having to re-add
the file at the old location if you wanted to keep it? I think currently
you're expected to locally delete it if you don't want to keep it (which
may not make sense, actually...)
> In my example, the edits I made to this file were
> actually automatically transferred to the new file ... Cool!.
Wow, I wish I knew why :)
AFAIK we have not yet added support for moving changes between moved
files. Maybe this has got to do with the copy improvements made in 1.5,
rather than the tree conflict work?
> So what
> do I do here? I guess maybe svn resolve would have done the right
> thing?
Well, the theory goes like this:
First, you think about what you want the merge result to be.
Then, you make the neccessary changes to your conflicted state
to achieve this result and run 'svn resolved' on the tree-conflicted
file (currently, you may still have to run 'svn resolved' on the file's
parent directory instead of the file itself, I'm not sure whether we've
fixed this yet).
> I did svn revert and the bug I am reporting is that this left
> ColorManager.java in my WC with a status of "Normal". So I edited the
> file and tried to commit and of course get the message that the file
> does not exist. So the bug is that the WC was not handled properly.
That sounds like a logic error we made here. Not sure how to handle
this. We agreed in the past that simply dropping a file from version
control was unacceptable because changes could get lost when the user
then forgets to re-add the file. However, now that we are screaming
"TREE CONFLICT" at the user anyway, we may want to reconsider leaving
the file unversioned (and saying so in the conflict description).
> My expectation was that svn revert would leave the file in the WC in
> an Unversioned status.
Because your initial expectation was also that the file would be
unversioned? I'm not saying this expectation was wrong, but we
need to agree upon what would be the best thing to do here.
In any case, users ending up in a conflicted state that is not
resolvable is unacceptable and needs fixing.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org