On May 3, 2006, at 23:53, Eric Hoch wrote:
> One of our developers recently copied the trunk of a project to
> a tag named "tags/Phase 4/trunk", and began committing changes
> against it. Since it's not entirely logical to commit changes
> against a tag, I set out to resolve this issue. I did the following:
>
> - I moved the "trunk" directory to the "branches" folder, creating
> "branches/trunk"
> - I renamed "branches/trunk" to "branches/Phase 4"
>
> Next, I attempted to update my working copy. Instead of updating to
> the latest version, which I expected to be the newly created
> branch, I received the following message:
> "Cannot replace a directory from within after a move."
>
> This isn't too big of a deal, since I can switch my working copy to
> the new URL. I was just expecting it to be a bit more "seamless", I
> guess.
Yeah, that's unfortunately the way it is right now. Updating the
working copy would have deleted it (since Subversion currently tracks
moves by deleting the old item, then adding the new one with
history), and you cannot delete an entire working copy while you're
within it. ("Cannot replace a directory from within.") "svn switch"
was the correct way to handle this. In the future, Subversion will
hopefully handle moves and renames with more grace, but it is a
difficult problem to solve and it will probably take a long time.
> Also, there was another developer working on the old path, and when
> she attempted to commit her changes to the now non-existant path,
> she received the same message. She then attempted an update and
> received the same message, but only after several files were
> deleted from her working copy, including files which had changed
> and were not yet comitted. She tried to revert, but obviously that
> would do no good since those changes existed only in the working
> copy. Is that the expected behavior?
Subversion policy is to not delete modified files, so this should not
have happened. What should have happened is that the modified files
should have been left where they were, and have become unversioned.
(That is, if you run "svn status", the formerly modified files should
now show up with the "?" status.) Did this not happen? If not, can
you provide a transcript of commands executed that resulted in the
loss of data, or can you recreate such a situation and provide a
transcript? If data is truly being lost, then I think that's
something the Subversion team would want to know about so they can
fix it. But without a transcript, we won't know if it's a bug or a
user error.
> Finally, what would be the best way to handle changes like this in
> the future, to avoid the issues outlined above?
Communicate the reorganization with your developers via an external
means (email, mailing list, forum, chat, phone, smoke signals,
alphabet soup) and advise them that they'll have to switch to the new
location.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 4 01:51:25 2006