On Fri, Dec 10, 2010 at 12:07 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: hyrum_at_hyrumwright.org [mailto:hyrum_at_hyrumwright.org] On Behalf Of
>> Hyrum K. Wright
>> Sent: vrijdag 10 december 2010 17:11
>> To: Subversion Development
>> Subject: Re: Conflict storage in 1.7
>>
>> Hearing no objections, I'm going to mark this as DONE.
>
> I don't think we can properly mark unversioned obstructions with just the
> current datastore. We need that storage to allow an update to complete
> regardless of obstructions.
> (And we can't keep the original behavior of 1.6 of unversioned obstructions
> as an unversioned directory obstructing a different directory wouldn’t be
> noticed with a single db).
Why can't we keep the original behavior of 1.6? Is there a behavior
regression (in which case, it wouldn't be the original behavior of
1.6)? Could you elaborate on the case you mention about? Or better
yet, author a test case to illustrate it?
> I would really like to see more of the enhanced conflict storage model in
> 1.7.
Will you then commit to implementing this behavior in a timely manner,
so as to not further delay 1.7?
> And until we get the code to a proper atomic behavior in the more common
> code paths (which I would call a show stopper) this can be implemented in
> parallel just fine.
>
>
> And I don't understand how you call something that hasn't been implemented
> 'DONE'. Maybe 'postponed' or something like that, but certainly not 'done'.
The bits about moving conflict information to the victim is done. Of
course there is always future work to be done, but my intent was to
call the bits required for 1.7 as DONE (particularly on roadmap.html).
I'm really just trying to get a better handle on what *needs* to be
done before a 1.7 branch, and a notes file which was written months
ago, but hasn't received much attention since then certainly feels
like something which can be punted on.
-Hyrum
Received on 2010-12-10 22:15:07 CET