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