You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Neels Janosch Hofmeyr <ne...@elego.de> on 2009/08/13 00:43:42 UTC
tree conflicts with replace
Hi tree-conflicts folks,
the irony, we were just discussing atomic replace, when a tree-conflict
failure with replaces in it pops up.
stsp received this issue on IRC from "KeeperOfTheSoul" on June 11th, his
paste was called m201b7297, which is attached in slightly tweaked form.
Let's discuss.
The reproduction script has two working copies, and *both* of them *replace*
a file 'alpha' atomically, BTW with conflicting content.
[[[
svn delete alpha;
echo "stuff" > alpha;
svn add alpha
]]]
The first WC commits fine. The second WC is forced to update and encounters
a tree-conflict.
`svn info' says:
[[[
Tree conflict: local delete, incoming delete upon update
Source left: (file) ^/trunk/alpha@1
Source right: (none) ^/trunk/alpha@2
]]]
--> IMHO that should say "local replace, incoming replace...". Replace is
not represented in the TC-info API (action/reason only have 'add', 'del',
etc. values. Maybe it's a nice bite-sized issue to add 'replace'?)
So, the user figures: "I revert my local changes, update and carry on from
there":
[[[
$ svn revert
Reverted 'alpha'
$ svn st
? alpha
]]]
--> Wait, the local changes were both a "delete" and an "add". Only the
"add" got reverted. Is that intended? BASE seems to be in-between the atomic
replace (sorry for the language). That's bad.
User figures: "I move alpha away so it won't become an obstruction when I
`update' the alpha from the repos".
[[[
$ mv alpha alpha.tmp
$ svn update
At revision 2.
]]]
No alpha is downloaded from the repos! The file is in fact missing but svn
thinks it is up-to-date.
Oh, but, if alpha is passed as an explicit target, everything is fine:
[[[
$ svn update alpha
A alpha
]]]
I can now compare alpha with alpha.tmp and manually merge the changes.
:/
--> The file alpha is in a weird state where it:
- is ignored in a recursive update, but not in an explicit one;
- has no marking at all (status omits it, seems up-to-date);
- does not exist in the WC but exists in the repos.
At first I tried to find a way to make "update" include "alpha" in the
recursive update. But now, I think it is better to prevent this state from
manifesting in the first place...
svn should ideally show a text-conflict on the two new 'alpha' files at some
point. It's the first thing any user would do: "what, the repos replaced the
file? I want to see the differences it has to my WC." Still, the user should
be notified that this is a tree-conflict, we can't just "silently" show a
text conflict.
What's the state of interactive tree-conflict resolution? I guess nonexistent.
This would also make sense: the first "update" should create those typical
text-conflict files in addition to marking the tree-conflict:
[[[
$ svn ci
'out of date'
$ svn up
C C alpha
$ svn st
? alpha.mine
? alpha.r2
C C alpha
> local replace, incoming replace upon update
$ svn info alpha
...
Tree conflict: local replace, incoming replace upon update
Source left: (file) file:///home/neels/.../repos/trunk/alpha@1
Source right: (file) file:///home/neels/.../repos/trunk/alpha@2
There is a text conflict.
Local version file: alpha.mine
Repos version file: alpha.r2
]]]
where alpha would be the (possibly completely conflicted) text merge of the
two (do this even though they are not "related").
So there is a text-conflict in the WC, plus the node 'alpha' is marked
tree-conflicted. 'alpha' could also be marked text-conflicted at the same
time. `svn info' should hint at the text conflict files. The user has all
the information available, fixes, runs `resolved', commits.
Plus, we skip the whole conflict thing if the resulting files are identical.
...so far I mentioned only the case where both sides replaced a file. But it
is also applicable in two more cases, where a replace collides with an edit,
see *:
incoming replace, local replace --> have text conflict files, mark TC *
incoming replace, local edit --> have text conflict files, mark TC *
incoming replace, local delete --> create file 'locally added', mark TC
incoming replace, local add --> not possible, must be a replace
incoming edit, local replace --> have text conflict files, mark TC *
incoming delete, local replace --> mark 'locally added', mark TC
incoming add, local replace --> not possible, must be a replace
possibly read "run interactive text conflict resolution" instead of "have
text conflict files", or even "run interactive resolution, revert to text
conflict files when postponed".
How does this translate to replacing directories? -- seems close to a
nightmare; this mail is long enough already.
Am I saddling the horse the right way here?
Thanks,
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383088
Re: tree conflicts with replace
Posted by Stephen Butler <sb...@elego.de>.
Quoting Vincent Lefevre <vi...@vinc17.org>:
> Hi,
>
> On 2009-08-13 02:02:42 +0100, Julian Foad wrote:
>> On Thu, 2009-08-13, Neels Janosch Hofmeyr wrote:
>> > [[[
>> > $ svn revert
>> > Reverted 'alpha'
>> > $ svn st
>> > ? alpha
>> > ]]]
>> >
>> > --> Wait, the local changes were both a "delete" and an "add". Only the
>> > "add" got reverted. Is that intended? BASE seems to be in-between
>> the atomic
>> > replace (sorry for the language). That's bad.
>>
>> That's got to be the root of this problem. Sounds like a simple bug. The
>> wierdness that follows it is not surprising, if it leaves the WC in a
>> bad state.
>
> Is this the same bug I've mentioned in my message
>
> svn 1.6.4 bug yields a working copy with missing data
>
> posted yesterday?
Yes.
>
> Is there an issue in the tracker?
I reopened issue 3334 "Tree conflict merry-go-round on update/switch"
http://subversion.tigris.org/issues/show_bug.cgi?id=3334
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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383469
Re: tree conflicts with replace
Posted by Vincent Lefevre <vi...@vinc17.org>.
Hi,
On 2009-08-13 02:02:42 +0100, Julian Foad wrote:
> On Thu, 2009-08-13, Neels Janosch Hofmeyr wrote:
> > [[[
> > $ svn revert
> > Reverted 'alpha'
> > $ svn st
> > ? alpha
> > ]]]
> >
> > --> Wait, the local changes were both a "delete" and an "add". Only the
> > "add" got reverted. Is that intended? BASE seems to be in-between the atomic
> > replace (sorry for the language). That's bad.
>
> That's got to be the root of this problem. Sounds like a simple bug. The
> wierdness that follows it is not surprising, if it leaves the WC in a
> bad state.
Is this the same bug I've mentioned in my message
svn 1.6.4 bug yields a working copy with missing data
posted yesterday?
Is there an issue in the tracker?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383217
Re: tree conflicts with replace
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Aug 15, 2009 at 11:18:43AM -0400, Mark Phippard wrote:
> On Sat, Aug 15, 2009 at 10:40 AM, Stefan Sperling<st...@elego.de> wrote:
> >> What are we discussing, again?
> >
> > I don't know. I just stumbled into this discussion because for some
> > reason what I read here made me realise that the above problem exists.
> >
> > When people hit this, and don't understand how the mergeinfo stuff
> > and 'svn revert' work, they will probably not realise that the real
> > problem is that they don't understand enough of the internal workings
> > of the tool and lack the corresponding insights into the tool's limitations
> > to be capable of dealing with the limitation they just hit.
> > And then they will [rightfully] blame Subversion for the problem,
> > i.e. they will blame us for not having fixed this limitation.
>
> I do not buy into this at all. There is no question that revert
> should also remove any mergeinfo changes on the target. If it didn't,
> then that would mean you could not revert ANY merge.
I agree that there is no technical problem.
> I also fail to see how this is confusing. If your normal merge patten
> is to merge all unmerged revisions (which is the basic scenario you
> are describing), then it makes perfect sense that you would need to
> use --record-only if there is a revision that you need to revert but
> do not want to keep merging in the future. I do not see any signs
> that users are confused by this part of merge.
It's more of a UI issue. People need to already know what you know to
arrive at these conclusions, and the UI as it is now is not giving them
a lot of hints.
Maybe a warning like this could help:
$ svn revert foo.c
svn: Warning: Reverted mergeinfo on foo.c,
run 'svn merge --record-only -r2:4 foo.c' to keep the merge recorded.
$
This would be the most naive way to fix the UI a small bit.
Then again, it's hard to draw a line where to add such warnings and where
they'll just get annoying.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2384045
Re: tree conflicts with replace
Posted by Mark Phippard <ma...@gmail.com>.
On Sat, Aug 15, 2009 at 10:40 AM, Stefan Sperling<st...@elego.de> wrote:
>> What are we discussing, again?
>
> I don't know. I just stumbled into this discussion because for some
> reason what I read here made me realise that the above problem exists.
>
> When people hit this, and don't understand how the mergeinfo stuff
> and 'svn revert' work, they will probably not realise that the real
> problem is that they don't understand enough of the internal workings
> of the tool and lack the corresponding insights into the tool's limitations
> to be capable of dealing with the limitation they just hit.
> And then they will [rightfully] blame Subversion for the problem,
> i.e. they will blame us for not having fixed this limitation.
I do not buy into this at all. There is no question that revert
should also remove any mergeinfo changes on the target. If it didn't,
then that would mean you could not revert ANY merge.
I also fail to see how this is confusing. If your normal merge patten
is to merge all unmerged revisions (which is the basic scenario you
are describing), then it makes perfect sense that you would need to
use --record-only if there is a revision that you need to revert but
do not want to keep merging in the future. I do not see any signs
that users are confused by this part of merge.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383866
Re: tree conflicts with replace
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Aug 14, 2009 at 05:14:42PM +0200, Neels Janosch Hofmeyr wrote:
> Stefan Sperling wrote:
> > On Fri, Aug 14, 2009 at 04:16:30AM +0200, Neels Janosch Hofmeyr wrote:
> >> So, someone merges from a branch, gets a conflict with an incoming replace.
> >>
> >> The 'revert' step is then useful as a resolving strategy of "wipe, get a
> >> clean slate, re-apply local changes manually". In that case, the merge would
> >> be carried out and recorded correctly.
> >
> > Unless maybe if the file has explicit mergeinfo?
>
> Well, incoming mergeinfo should be preserved. If there is explicit mergeinfo
> uncommitted in the working copy, sure. But isn't that what "revert" is
> supposed to be?
Say you have a file which ends up having explicit mergeinfo after a merge
of rX to your merge target. The parent's mergeinfo does not list rX,
but the file's mergeinfo now *does* list rX (locally in the WC).
Say also that you don't want the change rX made to that file.
You just want the version that's already in the merge target.
If people expect to use 'svn revert' as part of a conflict resolution
process after a merge, and 'svn revert' deletes mergeinfo property
changes on the file as well as the merged content changes, the merge
won't be recorded.
So, in other words, you have thrown away changes the merge brought in,
and you don't ever want them again because they conflict entirely with
your own changes. But because the mergeinfo on the file is also gone,
next time you merge, you get the same changes merged to the file again.
So you 'svn revert' the file again to get rid of the changes the merge
brought in. Again, the mergeinfo property changes also get revert.
It's an endless cycle.
$ svn merge -c3 ^/trunk/alpha alpha
--- Merging r3 into 'alpha':
U alpha
$ svn st
MM alpha
$ svn pl alpha
Properties on 'alpha':
svn:mergeinfo
$ svn revert alpha
Reverted 'alpha'
$ svn pl alpha
$
Unless people realise that the way to break the cycle is another
--record-only merge to the file in order to restore the mergeinfo
before commit. But I'd say no one will remember to do this.
$ svn merge --record-only -c3 ^/trunk/alpha alpha
$ svn st
M alpha
> What are we discussing, again?
I don't know. I just stumbled into this discussion because for some
reason what I read here made me realise that the above problem exists.
When people hit this, and don't understand how the mergeinfo stuff
and 'svn revert' work, they will probably not realise that the real
problem is that they don't understand enough of the internal workings
of the tool and lack the corresponding insights into the tool's limitations
to be capable of dealing with the limitation they just hit.
And then they will [rightfully] blame Subversion for the problem,
i.e. they will blame us for not having fixed this limitation.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383861
Re: tree conflicts with replace
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Stefan Sperling wrote:
> On Fri, Aug 14, 2009 at 04:16:30AM +0200, Neels Janosch Hofmeyr wrote:
>> So, someone merges from a branch, gets a conflict with an incoming replace.
>>
>> The 'revert' step is then useful as a resolving strategy of "wipe, get a
>> clean slate, re-apply local changes manually". In that case, the merge would
>> be carried out and recorded correctly.
>
> Unless maybe if the file has explicit mergeinfo?
Well, incoming mergeinfo should be preserved. If there is explicit mergeinfo
uncommitted in the working copy, sure. But isn't that what "revert" is
supposed to be? What are we discussing, again?
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383647
Re: tree conflicts with replace
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Aug 14, 2009 at 04:16:30AM +0200, Neels Janosch Hofmeyr wrote:
> So, someone merges from a branch, gets a conflict with an incoming replace.
>
> The 'revert' step is then useful as a resolving strategy of "wipe, get a
> clean slate, re-apply local changes manually". In that case, the merge would
> be carried out and recorded correctly.
Unless maybe if the file has explicit mergeinfo?
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383534
Re: tree conflicts with replace
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Bill Tutt wrote:
>
>
> On Thu, Aug 13, 2009 at 2:31 PM, Neels J Hofmeyr <neels@elego.de
> <ma...@elego.de>> wrote:
>
>
> Hi Bill,
>
> to keep the replace indivisible serves clarity and integrity of code
> semantics. You can always revert the whole replace and do a delete
> yourself
> after that.
>
>
>
> The revert would remove the merge history information if the replace
> came from a merge, right?
If I understand merge right, it should remove all the local changes, so, yes.
Different for update: update wants to pull the BASE to HEAD, so that it can
resolve conflicts later without having to contact the repos. So with a
conflict during update, a revert should ideally revert local changes _and_
update to the repository's state, right? That's how I understand revert:
"wipe my local changes, get me back to the most recent committed state I
have downloaded." Can you think of a use case where it is necessary/helpful
to be able to half-revert a local change?
> (Keep in mind I have no mental model for how Subversion merge history is
> implemented. I'm dealing (unfortunately) only with what I think might
> happen, and being a bit of a devils advocate to encourage discussion.)
>
> Wouldn't a subsequent merge between the two trees produce the replace
> again? That seems unfortunate.
So, someone merges from a branch, gets a conflict with an incoming replace.
The 'revert' step is then useful as a resolving strategy of "wipe, get a
clean slate, re-apply local changes manually". In that case, the merge would
be carried out and recorded correctly.
> Heh. Shouldn't 'svn undo' be an backward-3 way merge so you could 'svn
> undo' changeset (tip) and have as a result (tip-1)?
> Differentiating between 'undo' and 'revert' like you suggest seems like
> a very bad idea. If someone were to do anything like I'm suggesting then
> maybe it would be an additional option for 'svn revert'.
Yes, you're right. It's not good to have different granularity. -- So I am
thinking, when the replace was issued as a delete and an add that were a
couple of revisions apart, a three-way merge can still separate the two
operations. And it can be a meaningful choice to do a replace in a single
revision. Such a replace shouldn't be broken down into a fantasy half
revision, right?
But, sorry, what exactly are you suggesting, is it this?
[[[
$ svn st
R foo
$ svn revert --split-replace foo
partly reverted foo
$ svn st
D foo
]]]
My argument with tree-conflicts goes more like this:
[[[
$ svn st
R foo
$ svn up
C foo
$ svn st
C foo
> local replace, incoming replace upon update
$ svn revert foo
<foo now is on par with HEAD>
$ svn st
]]]
Partly reverting this case should probably split into four steps: revert
local add, revert local del, apply incoming del, apply incoming add. I think
it's not worth the trouble, really.
...above case currently fails in that, while `status' looks like everything
is as I intend it (it's empty), unfortunately `foo' is missing from the WC
and will only come back when passed as an explicit target to update.
Are we still talking about the same thing?
Thanks for the input, BTW.
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383507
Re: tree conflicts with replace
Posted by Bill Tutt <bi...@gmail.com>.
On Thu, Aug 13, 2009 at 2:31 PM, Neels J Hofmeyr <ne...@elego.de> wrote:
> Hi Bill,
> to keep the replace indivisible serves clarity and integrity of code
> semantics. You can always revert the whole replace and do a delete yourself
> after that.
>
>
The revert would remove the merge history information if the replace came
from a merge, right?
(Keep in mind I have no mental model for how Subversion merge history is
implemented. I'm dealing (unfortunately) only with what I think might
happen, and being a bit of a devils advocate to encourage discussion.)
Wouldn't a subsequent merge between the two trees produce the replace again?
That seems unfortunate.
> After a revert, the user should be sure that what is seen in the working
> copy corresponds with BASE, the state from last `update'.
>
> So, in the case where an incoming replace was downloaded during the update
> (which caused a tree-conflict) and I then `revert' the node in question,
> the
> working copy should show the new file from the repos.
>
> etc., I don't think splitting that up is a good idea. That would be better
> implemented as a separate command like `svn undo'. Patches welcome :P
>
> ~Neels
>
>
>
Heh. Shouldn't 'svn undo' be an backward-3 way merge so you could 'svn undo'
changeset (tip) and have as a result (tip-1)?
Differentiating between 'undo' and 'revert' like you suggest seems like a
very bad idea. If someone were to do anything like I'm suggesting then maybe
it would be an additional option for 'svn revert'.
Munching on all of this thought food,
Bill
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383419
Re: tree conflicts with replace
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Hi Bill,
to keep the replace indivisible serves clarity and integrity of code
semantics. You can always revert the whole replace and do a delete yourself
after that.
After a revert, the user should be sure that what is seen in the working
copy corresponds with BASE, the state from last `update'.
So, in the case where an incoming replace was downloaded during the update
(which caused a tree-conflict) and I then `revert' the node in question, the
working copy should show the new file from the repos.
etc., I don't think splitting that up is a good idea. That would be better
implemented as a separate command like `svn undo'. Patches welcome :P
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383407
Re: tree conflicts with replace
Posted by Bill Tutt <bi...@gmail.com>.
On Thu, Aug 13, 2009 at 11:52 AM, C. Michael Pilato <cm...@collab.net>wrote:
> Bill Tutt wrote: > I've always thought that a pending "replace" when
> reverted should
> > decompose into the underlying operations and only revert the non-delete
> > operation.
> >
> > That way the svn status command in your above example would output:
> > [[[
> > svn st
> > D alpha
> > ]]]
> >
> > The idea behind this behavior is the svn command line shouldn't mind
> > read the user's intention behind issuing the revert command.
> > svn doesn't know if the user wants to revert the delete as well as the
> add.
>
>
> 'svn revert' has a very clear meaning today, though, which would be muddled
> by the behavior you suggest: "restore TARGET to an unmodified state".
> It's
> for this reason that we didn't name the command 'svn undo', which would
> imply a stack of reversible operations.
>
>
>
The alternative would be to not allow the replace in the first place. Then
you'd never have a stacked operation in this particular context. However,
that makes merging much more annoying. You'd have to break the merge into
two halves one including the deletes, and the other the replaces (add,
copy, or move). Ugh. However, you wouldn't have replaces and thus no
stacking. The standard 'be consistent' argument would say pick one or the
other. ;)
Multiple pending directory moves can also create an implied stack of
operations as well with regard to their repository path. Admittedly, this is
a different kind of stack of operations... IF Subversion supported something
like this then:
directory tree A\B\C\D
svn mv A\B\C\D A\B\D
svn mv A\B B
svn revert B
resulting path for items contained by D: A\B\D
Reverting B didn't restore B to its original state because it still
contains the pending move of D. i.e. stacking operations
Or an even simpler:
svn mv a.cs temp.cs
svn mv b.cs a.cs
svn mv temp.cs a.cs
This is also an operation stack, but again of a different sort. In this case
life is simple because 'svn revert a.cs' would hopefully produce something
along the lines of:
'Error: Cannot revert a.cs because a pending move is currently at b.cs'
To sum up:
It seems kind of odd you can't undo a portion of the merge before submitting
your changeset with 'delete/(add, copy, move)' changes. So maybe you
shouldn't think of it as muddling revert, but allowing the user preforming a
merge (or individual command lines) to get the resulting changes they want
in the easiest way possible. The user pain in redoing the merge for just
that item seems high enough to at least consider it.
Food for thought,
Bill
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383394
Re: tree conflicts with replace
Posted by "C. Michael Pilato" <cm...@collab.net>.
Bill Tutt wrote:
> I've always thought that a pending "replace" when reverted should
> decompose into the underlying operations and only revert the non-delete
> operation.
>
> That way the svn status command in your above example would output:
> [[[
> svn st
> D alpha
> ]]]
>
> The idea behind this behavior is the svn command line shouldn't mind
> read the user's intention behind issuing the revert command.
> svn doesn't know if the user wants to revert the delete as well as the add.
'svn revert' has a very clear meaning today, though, which would be muddled
by the behavior you suggest: "restore TARGET to an unmodified state". It's
for this reason that we didn't name the command 'svn undo', which would
imply a stack of reversible operations.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383337
Re: tree conflicts with replace
Posted by Bill Tutt <bi...@gmail.com>.
On Wed, Aug 12, 2009 at 9:02 PM, Julian Foad <ju...@btopenworld.com>wrote:
On Thu, 2009-08-13, Neels Janosch Hofmeyr wrote:
> Hi tree-conflicts folks,
>
> the irony, we were just discussing atomic replace, when a tree-conflict
> failure with replaces in it pops up.
Hi Neels.
>
> There are several tree-conflict deficiencies and bugs such as this one
> that I'd like to take a look at some time, but I've been doing other
> things instead.
>
> [...]
> > [[[ > $ svn revert
> > Reverted 'alpha'
> > $ svn st
> > ? alpha
> > ]]]
> >
> > --> Wait, the local changes were both a "delete" and an "add". Only the
> > "add" got reverted. Is that intended? BASE seems to be in-between the
> atomic
> > replace (sorry for the language). That's bad.
>
>
I've always thought that a pending "replace" when reverted should decompose
into the underlying operations and only revert the non-delete operation.
That way the svn status command in your above example would output:
[[[
svn st
D alpha
]]]
The idea behind this behavior is the svn command line shouldn't mind read
the user's intention behind issuing the revert command.
svn doesn't know if the user wants to revert the delete as well as the add.
Note: I'm purposefully not suggesting what the directory state should be for
the above svn status output in the WC. I merely bring this up to encourage
discussion.
Bill
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383315
Re: tree conflicts with replace
Posted by Julian Foad <ju...@btopenworld.com>.
On Thu, 2009-08-13, Neels Janosch Hofmeyr wrote:
> Hi tree-conflicts folks,
>
> the irony, we were just discussing atomic replace, when a tree-conflict
> failure with replaces in it pops up.
Hi Neels.
There are several tree-conflict deficiencies and bugs such as this one
that I'd like to take a look at some time, but I've been doing other
things instead.
[...]
> [[[
> $ svn revert
> Reverted 'alpha'
> $ svn st
> ? alpha
> ]]]
>
> --> Wait, the local changes were both a "delete" and an "add". Only the
> "add" got reverted. Is that intended? BASE seems to be in-between the atomic
> replace (sorry for the language). That's bad.
That's got to be the root of this problem. Sounds like a simple bug. The
wierdness that follows it is not surprising, if it leaves the WC in a
bad state.
[...]
> Am I saddling the horse the right way here?
All you said about text conflicts etc. sounds like good ideas for
improvement.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383093
Re: tree conflicts with replace
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Neels Janosch Hofmeyr wrote:
> stsp received this issue on IRC from "KeeperOfTheSoul" on June 11th, his
> paste was called m201b7297, which is attached in slightly tweaked form.
and here it is.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383091