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

Re: bug in add/add tree conflict?

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 22 Apr 2009 18:41:04 +0100

On Wed, Apr 22, 2009 at 06:51:02PM +0200, Stephen Butler wrote:
> We can't reschedule the existing added-with-history item as
> "replaced", because it doesn't exist on the server yet. Is that
> correct, anyone?

I think the idea proposed by Greg is the following:

The incoming item is already versioned. It is safe, it can
be recovered from history.

The locally added item has not reached the repository yet,
it is not "safe" yet in the sense that a backup of it
could be retrieved from the repo at any time.

So the safest thing to do is to automatically replace the
incoming item by the locally added item.

The status of the local item gets upgraded from "locally
added (with history or whatever)" to "replacing the item
that the update just tried to add".

The item the update tried to add is added as the revert base,
so that "svn revert" reverts the local change, which makes the
incoming item appear as schedule normal, as of the revision
we last updated to. People already know that running "svn revert"
means losing their local changes, so that should be fine.

Does this make sense to you? Is there a problem with that approach
which we're not seeing?

The revert approach definitely won't work with wc-1 for directories,
because we can't store an entire directory tree as a revert base for
another directory. That concept just does not exist in wc-1.
Hopefully wc-ng can fix that.

Stefan
Received on 2009-04-22 19:41:48 CEST

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.