On Feb 27, 2005, at 10:19 PM, S.Ramaswamy wrote:
> If a file or directory that is scheduled for addition, is copied from
> the working copy to the repository directory from which the file's
> parent directory was checked out, then the next update or commit
> results
> in an error, since the file already exists. For instance, in a wc
> checked out from trunk, if a file test.txt that is scheduled for
> addition is copied to the respository trunk, the subsequent update or
> commit gets aborted.
>
> Is this an edge condition, that is up to the user to handle, or would
> it
> be a good idea to put in a check to prevent files scheduled for
> addition, from being copied to the parent directories url ?
>
This seems like pilot error. I imagine another variant is editing a
file in then running
svn copy working-copy URL-of-working-copy
svn update
... which would cause the same sort of 'obstructed' update... or at
least a conflict, since the repository will be trying to add a change
to a file that already has a the same change as a local modification.
These sorts of errors also happen whenever the an 'svn commit' succeeds
in the server, but the network drops, leaving the working copy thinking
that the commit never happened. The next 'svn update' is nothing but
redundant obstructions.
The moral of the story is: "don't run 'svn cp wc URL' when the wc has
local changes, unless you understand what you're doing". I don't see
any reason to protect people here: there's no risk of data loss, just
a possible obstructed update that can be easily cleared away.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 28 05:43:32 2005