Quoting "Neels J. Hofmeyr" <neels_at_elego.de>:
> Hey guys,
>
> we have to get things back in line... attempting:
>
> 1. Neels suggests fix of TC-sibling bug by collecting all added TCs in an
> apr_array until closed_directory().
>
> 2. Steve suggests writing TCs immediately, Neels implements.
>
> 3. Greg says "no".
>
> 4. Steve reverts (2) and says he's onto fixing it by adding an
> <wc-entry-add-tree-conflict/> instruction to the log (suggested by neels).
>
> 5. Julian says that this is not fixing the synchronization problem.
>
> 6. Julian says he likes solution (1) above.
>
> 7. Steve explains the concept of 4 in more detail.
>
> 8. Steve verifies that it is necessary to write TCs on delete immediately.
>
> 9. Julian acknowledges that "update" may not be entirely loggy after all.
>
>
> To 1, 6: There would be the log on the one hand and the TC list on the other
> hand. Afterwards, there is no way of knowing *when* in the log the TCs were
> added. However, if that doesn't matter, this solution would be nice in that
> it only once reads pre-existing conflicts and appends new conflicts in one
> chunk instead of resizing buffers on every new tree-conflict. (whatever.)
>
> To 5: Julian, I don't really understand the synchronization problem with
> this solution you are talking about. It writes distinct "add this conflict"
> commands to the log which get run within the sequence of the log. Each one
> performs a "read first" to append one new conflict, which is a little bit of
> overhead. But the sequence of events should be proper, shouldn't it? Note,
> this one requires creating a new log command, one that *appends* a conflict
> to the parent's entry instead of *replacing* conflicts in the parent's entry.
>
>
> To the current situation:
> Who is doing what now?
>
> As to "what": I am still convinced that (5) is the best solution.
Do you mean (4)?
>
> As to "who": Steve, should I continue on this or would you like to?
> (I'm often not entirely clear on whether you are really taking over
> something I've been working on or getting back to other stuff. We *could*
> actually work alternately on the same issues, because I work at nights and
> you work at daytime (I assume). For example, at the end of the working day,
> each of us posts a diff of any unfinished work on a joint issue and the next
> guy tries to make sense of stuff from there... :) Or we use branches. That
> used to work pretty nicely IMHO.)
> Anyway, please be more verbose about things we are working on together. :)
Can do!
>
> I'm letting you guys reply on this and am first looking at something
> entirely different. If we are clear on this tomorrow, I would gladly
> continue to fix it, unless someone else says he's busy on it.
>
OK, I'll work on (4) this afternoon, make one or two commits or a patch,
and you can take over this evening.
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-18 09:25:21 CET