[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 17 Sep 2010 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.

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

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

Received on 2010-09-17 13:55:21 CEST

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