On Wed, Dec 12, 2012 at 4:33 PM, Asbjørn Sæbø <gaffe_1_at_live.com> wrote:
>
>
> Dear TortoiseSVNers,
>
> We have just seen a case where a file has been lost as a combination
> of renaming and merging. We must understand how this could happen, so
> that we can avoid similar situations in the future.
First important question is: which version of (Tortoise)SVN was being
used on the clients which performed the actions below? And the server?
[ snip ]
> ======================================================
>
> 5) 6245 - Merge product branch to active signal branch to keep in sync
>
> Revision: 6245
> Author: nvlsi\sac
> Date: 11. desember 2012 17:51:16
> Message:
> [...] merged the product branch [...] to active signal branch
> ----
> [...]
> Modified : /verification/branches/development/DRGN-740_active_signal
> Deleted : /verification/branches/development/DRGN-740_active_signal/doc/test_result/030_system_level_test_documentation.dox
> Modified : /verification/branches/development/DRGN-740_active_signal/framework/builds/DragoonTools.manifest
> [...]
>
> !!!!! Note that only the deletion from 6190 was merged, not the addition of the renamed file !!!!!!!!
>
One possible explanation could be "user error". It's possible that the
user who carried out this merge, in his working copy, deleted the file
/verification/branches/development/DRGN-740_active_signal/doc/test_result/030_system_test_level.dox
from his working copy, prior to committing the merge result to the
repository. In that case, the user does something to the merge result
before committing it (this can be seen as a form of "merge conflict
resolution" done by the user). This could be unintended, for example
if the user got a tree conflict on that file, and didn't really know
how to resolve it, and finally ended up deleting it. But it can also
be perfectly reasonable, for example if the user saw some "semantic
conflict" (not flagged automatically, because on a file / line level
everything is ok), and the user then decides to get rid of this file.
It's just a possibility. The only thing you can do against that is 1)
making sure people (or colleagues) review what they are committing,
and 2) running some continuous integration build on your branch to
catch the error early.
--
Johan
Received on 2012-12-12 18:58:24 CET