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
> 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
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
tel/fax: (+370-5)-210 40 05
mobilus: (+370-684)-49802, (+370-614)-36366
Received on Sun Dec 4 18:10:54 2005
- application/pgp-signature attachment: stored