Re: Switching to temp branch causes "Failed to add file 'fileB.txt': object of the same name already exists"

On Tue, 2004-02-03 at 08:07, Ben Collins-Sussman wrote:

> So the real question here (for developers): is the copy behavior doing
> the right thing in this scenario?

After some more thinking (and chatting with cmpilato), I don't think
there's any bug here.

The confusion comes from two different interpretations of what 'svn cp
WC URL' means. I'm guessing Francois is thinking of the operation as a
type of commit. And it *is* a type of commit, insofar as it creates a
new revision in the repository. But it's really *very* different from
the 'svn commit' command.

The 'svn commit' command necessarily causes the working-copy to change
after the commit, local mods (both textual changes and tree schedulings)
no longer exist. Revision numbers have been increased.

But 'svn cp WC URL' is nothing like that... it's purpose is to merely
take a "snapshot" of a working copy and put the snapshot somewhere in
the repository. By definition, a copy command *never* modifies the
source of the copy. Looking at the working copy, there's no way to tell
that the 'svn cp WC URL' was ever run: local mods still exist, revnums
are unchanged, and schedule-adds are still there too. It would be crazy
for 'svn cp WC URL' to start doing the same things that 'svn commit'
does. This 'svn cp' codepath is merely trying to duplicate data, not
create new relationships between the WC and repos.

So in Francois' scenario, he had a working-copy with various changes in
it (local mods, plus schedule-add files), and wanted the whole
working-copy to become an unmodified reflection of a new branch. There
are at least two ways to accomplish this:

1. Make the branch by running 'svn cp URL URL'. Then 'svn switch' your
working copy to that branch, and 'svn commit' your local mods.

2. Make a data snapshot of the WC by running 'svn cp WC URL'. Then
'svn revert' all your local mods and 'svn switch' to the new branch.

It looks like Francois took the second route. I think the first route
is a little cleaner and easier to understand.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 3 19:48:19 2004