Sorry if this comes through twice, but it didn't seem to send yesterday.
Ryan Schmidt wrote:
> 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.
>
Understood. If switch was definitely the correct action, shouldn't the
client perform that on an update, rather than the delete/add process
that currently happens? Are there situations where the current process
is the preferred one?
>> 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.
I'll see what I can get from the developer. I tried to recreate the
situation by checking out the revision before the move, changing files,
and then updating. In my case, nothing was deleted, only the error
message was displayed.
>> 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.
Understood. I had planned to notify the developers, this one just beat
me to it. I will communicate these types of changes ahead of time from
now on.
-Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 5 15:31:21 2006