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

Re: atomic-revprop mergeability, with 1.7 in mind

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 18 Sep 2010 09:41:46 +0100

C. Michael Pilato wrote on Fri, Sep 17, 2010 at 07:54:34 -0400:
> On 09/17/2010 03:17 AM, Daniel Shahaf wrote:
> > In other words, the branch implements the API correctly and (from an
> > FS-oriented point of view) completely, and only the ability to signal to
> > the caller what sort of error condition occurred is absent. That
> > absence means a caller cannot tell[*] whether the propchange failure was
> > due to requesting an atomic change or due to some other reason.
> >
> > Is it fine to merge the branch to trunk, given this state? Is the
> > branch, in its current state, fit for release (in 1.7), or is additional
> > work (possibly including the abovementioned errorcode work) required
> > prior to releasing it?
> Something tells me that a unique errorcode for atomicity failures will be
> useful. What will change on the client(s) behavior-wise if there is a new
> errorcode? I dunno. Maybe it can use the conflict resolution callback
> system to prompt the user to resolve what now could be conveyed as a
> conflict between their proposed revprop edit and the one that slipped in
> underneath them. Error string comparison (your noted workaround) is a
> non-starter -- let's not even speak of such things.

I agree that it's evil and ugly. That's why I haven't committed it (not
even to the branch).

> That said, it sounds like the code isn't a danger to the trunk. So the
> question really becomes, "Will you (or someone you know) see this task
> through to completion before 1.7 ships?" If you fully intend to do so, I
> don't see a problem with merging back to trunk ASAP (and updating
> roadmap.html not to point to the now-obsolete BRANCH-README).

I'll work on this and see this through to completion.

I'm not comfortable committing to dates on this work, since it's mostly
single-handed and I work on this between doing other things (which are
more important to me right now).

Do you think the featureset currently on the branch is releaseable? If
not, what do you think should be added to make it releaseable?

> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-09-18 10:42:49 CEST

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