Re: weird behavior with simultaneous edit and move

On Sunday 04 December 2005 07:03, Kent Tong wrote:
> Would anyone confirm the following weird behavior with simultaneous
> edit and move?
>   client 1: renames F1 to F2.
>   client 2: edits F1.
>   client 1: commits.
>   client 2: synchronizes. F2 will appear as a new file (incoming
> change). F1 will be marked as in conflict with the content of F2.
>   client 2: marks F1 as resolved. Updates. Then F1 will become an
> unversioned file! It means he will have both F1 and F2! And F2
> doesn't contain the changes he made.

To my taste, this looks as completely expected and normal behavior. Since user
1 renamed F1, thus effectively removing it from version control, any file
named F1 from that point on becomes unversioned.

Since user 2 had local changes to the file F1, the file is not removed but
left alone. Since user 2 accepted deletion of file F1 by saying "resolved",
the file becomes unversioned. User 2 is now free to do whatever he/she wants
with file F1 -- add and commit, remove, copy to a safe location, etc.

Actually, another possibility for subversion would have been to commit F1
back into the repository after user 2 said "resolved", but I am not sure if
this is a better behavior. After all, what used to be F1 is now F2, and
having the same thing twice is hardly the intention of users' 1 and 2. Or am
I wrong?

> This is a very dangerous behavior.

What is so dangerous about it? If I understand you correctly, no information
was lost. The file F1 was left in user's 2 directory, with all local changes
-- I see this as a safe and correct option in the situation above.

> If it is confirmed, is there any
> plan to solve this problem?

I do not see what is the problem that is to be solved. Could you please be
more specific?

-- 
Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax:      (+370-5)-210 40 05
mobilus:      (+370-684)-49802, (+370-614)-36366