Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > Re: bug in add/add tree conflict?

subversion
Discussion topic

There will be a brief maintenance window every Friday at 17:00 Pacific.
For further details, see CollabNet's maintenance and upgrade policy.

Back to topic list

Re: bug in add/add tree conflict?

Author gstein
Full name Greg Stein
Date 2009-04-22 11:05:22 PDT
Message On Wed, Apr 22, 2009 at 19:41, Stefan Sperling <stsp at elego dot 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@SOMEREV file2
$ edit file2

IOW, file2 is now schedule-replace and I can revert to what came down
in the update.

(it is "file1@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

« Previous message in topic | 8 of 10 | Next message in topic »

Messages

Show all messages in topic

bug in add/add tree conflict? gstein Greg Stein 2009-04-21 17:27:42 PDT
     Re: bug in add/add tree conflict? stsp Stefan Sperling 2009-04-22 03:57:00 PDT
         Re: bug in add/add tree conflict? gstein Greg Stein 2009-04-22 04:14:24 PDT
             Re: bug in add/add tree conflict? Paul Burba <ptburba at gmail dot com> Paul Burba <ptburba at gmail dot com> 2009-04-22 07:53:14 PDT
                 Re: bug in add/add tree conflict? gstein Greg Stein 2009-04-22 08:35:17 PDT
                     Re: bug in add/add tree conflict? sbutler Stephen Butler 2009-04-22 09:51:07 PDT
                         Re: bug in add/add tree conflict? stsp Stefan Sperling 2009-04-22 10:41:33 PDT
                             Re: bug in add/add tree conflict? gstein Greg Stein 2009-04-22 11:05:22 PDT
                                 Re: bug in add/add tree conflict? stsp Stefan Sperling 2009-04-22 11:31:45 PDT
                                     Re: bug in add/add tree conflict? gstein Greg Stein 2009-04-22 11:59:23 PDT
Messages per page: