Re: deleted-with-history [sic] after merge

["C. Michael Pilato" <cm...@collab.net>]

David Glasser wrote:
> On Fri, Feb 29, 2008 at 1:58 PM, Ben Collins-Sussman
> <su...@red-bean.com> wrote:
>> On Fri, Feb 29, 2008 at 11:06 AM, David Glasser
>>  <gl...@davidglasser.net> wrote:
>>
>>  >  You sure?  From 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));
>>
>>  I have a vague recollection of this code flip-flopping back and forth
>>  over the years, and cmpilato being at the helm of such decisions.
>>  Mike, can you remember what's up here?
> 
> So what happens (this is based on both reading and running the code)
> is that *most* of the time double deletes are ignored.  However, if
> Client #2 starts its commit drive after Client #1 starts its commit
> drive but before Client #1 finalizes its commit, you'll get an error
> from the quoted code above.  (I was able to reproduce this by running
> Client #1 under gdb and throwing in a breakpoint.)

Right.  The flip-flopping Ben might be thinking of is that we used to build 
our commit transactions against the revision used to open the commit 
editor's root directory; now we always build the commit transaction against 
HEAD.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand