[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflict merry-go-round on update/switch

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 25 Nov 2008 19:10:26 +0000

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, 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.)


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.