On Wed, Apr 22, 2009 at 19:41, Stefan Sperling <stsp_at_elego.de> wrote:
> 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.
Not entirely true. It may have local mods after the copy occurred.
> 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".
Right.
Let's say I did the following:
$ svn cp file1 file2
$ edit file2
$ svn up
> incoming add conflicts with my add
$ svn resolve --accept=working
The result (I believe) should be the same as if I did the following:
$ svn up
$ svn rm file2
$ svn cp file1_at_SOMEREV file2
$ edit file2
IOW, file2 is now schedule-replace and I can revert to what came down
in the update.
(it is "file1_at_SOMEREV" to indicate that (strictly speaking) I need to
make the copy from before the "svn up"; regardless, the point is that
file2 ends up in "schedule replace" in both approaches)
> 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.
"svn update" can virtually populate the entire BASE tree and drop
pristine files into its filestore. It only gets tricky when you start
comparing the BASE changes against what is in WORKING and ACTUAL.
That's where the tree conflicts will come in. But if you have a
local-copy sitting in WORKING, and then revert that... yes, we can
restore the entire directory structure from the recorded BASE and the
files stored in the filestore. No problem at all!!
:-) :-)
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1863843
Received on 2009-04-22 20:05:36 CEST