You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Francois Beausoleil <fb...@users.sourceforge.net> on 2004/02/03 13:50:41 UTC
Switching to temp branch causes "Failed to add file 'fileB.txt': object of the same name already exists"
Hello everyone !
I believe I found a small bug when creating a temporary branch from a WC.
In my WC, I had added a few files. I did svn copy WCPATH URL, which did
an immediate commit. I then tried to switch to the branch in question.
The added files were still in my WC, which caused problems, because they
were in the way.
I believe SVN should have been intelligent enough to notice that the
files
were the same between the branch and the WC, and should have simply
updated
the admin area to say that the files were freshly copied out of the
repos.
The following recipe exposes the "bug" (sample run at end):
rd /s/q repos wc
cls
svnadmin create repos
svn checkout file:///repos wc
cd wc
md trunk branches tags
cd trunk
echo >fileA.txt "File A's content"
cd ..
svn add trunk tags branches
svn commit --message "Initial repository layout"
cd trunk
echo >fileB.txt "File B's content"
svn add fileB.txt
svn copy . file:///repos/branches/temp-branch --message "Creating
temporary branch"
svn switch file:///repos/branches/temp-branch
svn revert --recursive .
del fileB.txt
svn switch file:///repos/branches/temp-branch
You'll notice that after I delete fileB.txt, the switch correctly occurs.
Does anyone else think this is a bug, or is this "normal behavior" ?
This is on Win2K SP4, SVN 0.37.0.
Thanks !
François
============== Sample Run ==============
$ svnadmin create repos
$ svn checkout file:///repos wc
Checked out revision 0.
$ cd wc
$ md trunk branches tags
$ cd trunk
$ echo "File A's content" 1>fileA.txt
$ cd ..
$ svn add trunk tags branches
A trunk
A trunk\fileA.txt
A tags
A branches
$ svn commit --message "Initial repository layout"
Adding branches
Adding tags
Adding trunk
Adding trunk\fileA.txt
Transmitting file data .
Committed revision 1.
$ cd trunk
$ echo "File B's content" 1>fileB.txt
$ svn add fileB.txt
A fileB.txt
$ svn copy . file:///repos/branches/temp-branch --message "Creating
temporary branch"
Committed revision 2.
$ svn switch file:///repos/branches/temp-branch
svn: Failed to add file 'fileB.txt': object of the same name already
exists
$ svn revert --recursive .
Reverted 'fileB.txt'
$ del fileB.txt
$ svn switch file:///repos/branches/temp-branch
A fileB.txt
Updated to revision 2.
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Switching to temp branch causes "Failed to add file'fileB.txt': object of the same name already exists"
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
Well, it's Ok. I wasn't sure it was really a bug. I understood where
the problem came from.
On Tue, 03 Feb 2004 12:44:22 -0600, "Ben Collins-Sussman"
<su...@collab.net> said:
> On Tue, 2004-02-03 at 08:07, Ben Collins-Sussman wrote:
[snip]
>
> 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.
I was lazy that day :) I didn't feel like waiting for switch to occur,
so I simply svn cp'd the whole thing to a temporary branch, and would
have continued on the morrow.
[snip]
Thanks for taking the time to respond.
Bye !
François
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Switching to temp branch causes "Failed to add file
'fileB.txt': object of the same name already exists"
Posted by Ben Collins-Sussman <su...@collab.net>.
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
Re: Switching to temp branch causes "Failed to add file 'fileB.txt':
object of the same name already exists"
Posted by Ben Collins-Sussman <su...@collab.net>.
Francois Beausoleil wrote:
> $ svn add fileB.txt
> A fileB.txt
>
> $ svn copy . file:///repos/branches/temp-branch --message "Creating
> temporary branch"
Hm, if there *is* a bug here, it might be related to this copy command.
I don't really understand how our 'svn cp WC URL' codepath behaves
when it sees files scheduled for addition. It looks to me as though it
does not ignore them, but instead(1) commits them, (2) leaves them still
scheduled for addition. Is that the case? And is that correct?
(Thoughts?)
> $ svn switch file:///repos/branches/temp-branch
> svn: Failed to add file 'fileB.txt': object of the same name already
> exists
...in which case, this behavior is no surprise. When the client
describes its working copy to the server, it never mentions files
scheduled for addition. They're not yet officially part of any revision
yet. So during the swith (update), the server is trying to add a file
by the same name, and gets a standard tree-conflict with the
schedule-add file.
So the real question here (for developers): is the copy behavior doing
the right thing in this scenario?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org