Subversion is presently inconsistent about whether a delete conflicts with a
delete, when auto-merging transactions in the repository.
See this email <http://svn.haxx.se/dev/archive-2008-03/0972.shtml> in the thread
starting at <http://svn.haxx.se/dev/archive-2008-02/0872.shtml>.
The low-level behaviour should be to treat delete+delete strictly as a conflict,
even though, at the user's level, double deletion is often harmless. This is
partly because a low-level delete doesn't necessarily correspond to a user-level
delete, it could be part of a user-level rename.
The bug (though it was intentional at the time) is in
subversion/libsvn_repos/commit.c(delete_entry):
/* If PATH doesn't exist in the txn, that's fine (merge
allows this). */
if (kind == svn_node_none)
return SVN_NO_ERROR;
While we're here, there's an inconsistency in libsvn_fs_fs/tree.c(merge):
/* If SOURCE-ENTRY and TARGET-ENTRY are both null, that's a
double delete; flag a conflict. */
if (s_entry == NULL || t_entry == NULL)
return conflict_err(conflict_p,
svn_path_join(target_path,
a_entry->name,
iterpool));
The code doesn't match the comment. The code says "or", the comment says "and".
I haven't looked to see which is correct or whether it's just that the comment
is incomplete in not mentioning the other cases.
Bug
Critical
