[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Conflict storage in 1.7

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 10 Dec 2010 21:07:06 +0100

> -----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).

I would really like to see more of the enhanced conflict storage model in

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'.


> -Hyrum
> On Wed, Dec 8, 2010 at 11:09 AM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
> > The current state of conflict storage is such that all conflict
> > information is stored on the victim's node in the database.  While
> the
> > plan described in notes/wc-ng/conflict-storage is admirable, it
> > requires much more work than just shuffling data bits around, and I'm
> > hesitant to start in on it prior to branching 1.7.  With that being
> > said, I think that the current state of conflict storage is Good
> > Enough for 1.7 (though could certainly be improved in the future).
> >
> > Does anybody have concerns about releasing the current format in 1.7?
> >
> > Thanks,
> > -Hyrum
> >
Received on 2010-12-10 21:07:47 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.