On Tue, Nov 25, 2008 at 06:53:44PM +0100, Stephen Butler wrote:
> Quoting Stephen Butler <sbutler_at_elego.de>:
> The fresh tree conflict is not exactly wrong, because the existence of
> the local mods means that the tree conflict still exists "on the
> ground".
>
> A user workaround is to
>
> 1. non-svn-move the modified victim elsewhere
>
> 2. resolve the victim
>
> 3. update (deleting the victim & descendants)
>
> 4. copy the old victim back into the wc
>
> 5. non-svn-move the modified victim back, overwriting the old
> version
I can confirm that this workaround works:
$ mv alpha alpha.non-svn-moved
$ svn resolved alpha
Resolved conflicted state of 'alpha'
$ svn up
Restored 'alpha'
D alpha
Updated to revision 2.
$ svn cp ^/trunk/alpha_at_1 .
A alpha
$ mv alpha.non-svn-moved alpha
$ svn diff
Index: alpha
===================================================================
--- alpha (revision 2)
+++ alpha (working copy)
@@ -1 +1 @@
-alpha
+alpha, modified
$ svn commit -m works
Adding alpha
Transmitting file data .
Committed revision 3.
$
And if you want to keep alpha deleted:
$ rm alpha
$ svn resolved alpha
Resolved conflicted state of 'alpha'
$ svn up alpha
Restored 'alpha'
D alpha
Updated to revision 2
$ svn status
$
> This is awkward for directory victims, which take .svn dirs with
> them. The user should run svn export to extract unversioned items.
Ooooh, svn export is now part of the tree conflict toolset! :)
We should try to find a solution that is more intuitive, if possible.
We should at least make sure to communicate to users when text-bases
aren't updated the way they might expect...
In any case, having to move local changes somewhere else temporarily
may turn out to be unavoidable.
> Fixing this issue would allow the user to
>
> 1. resolve the victim
>
> 2. update (deleting the victim & descendants, leaving local mods
> unversioned)
>
> 3. non-svn-move the local mods elsewhere
>
> 4. copy the old victim back into the wc
>
> 5. non-svn-move the unversion local mods back, overwriting the old
> version
>
> Because svn copy doesn't support a --force option like update and
> switch do, the use has to move the modified victim manually before
> copying the older version into the working copy. At least, it's
> easier this way, moving a nonversioned victim.
>
> Comparing the two workarounds above, the difference isn't as stark as
> I first expected. I suppose svn copy --force would be nice to have.
They're the same, expect steps 1 to 3 are reversed, and you don't
have the hassle of .svn directories for directory victims.
Probably slightly more intuitive, but really the best we can come up with?
> Fixing this issue would require changing the data structures in the
> working copy library, and changing the behavior of commands that
> create and read tree conflicts. Is that allowed after branching 1.6?
We could also decide to live with the known workaround,
if we can't find a better solution in time.
The strategy used in the workaround can be described as follows,
and may also be useful for other scenarios:
1) Make local changes which allow the incoming change to succeed.
2) Mark resolved.
3) Run 'svn update' to update victim text bases and pull in the
incoming change without a tree conflict being flagged.
4) Make local changes to reflect your own (possibly conflicting)
change, and commit if necessary.
I'd argue that once you grok the fact that text-bases aren't updated
when a tree conflict is flagged, this strategy is straightforward.
The question then is: Why don't we just update the text-base again? :)
(I honestly have forgotten the exact reason for this.)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-25 20:10:42 CET