On Fri, Feb 13, 2009 at 02:14:18PM -0500, James Y Knight wrote:
> On Feb 12, 2009, at 10:17 PM, Stefan Sperling wrote:
> > We decided not to treat obstructions as tree conflicts.
> > See issue #3161 for details:
> > http://subversion.tigris.org/issues/show_bug.cgi?id=3161
> Too bad. I really agree with the tree-conflict documentation's remark
> on merge's skipping behavior:
> "Skipping obstructed items during merge is no longer acceptable
> behaviour, since users might not be aware of obstructions that were
> skipped when they commit the result of a merge."
> I find this failure rather insidious, as unless the developer is
> attentive, they might think the merge actually worked. Compiles and
> tests in the working copy will all work correctly, as the files got
> unversioned but are still prevent. I find developers to not always be
> attentive, so it would be nice if the tool would help to prevent this
And that is why 1.6 handles many use cases which had exactly the problem
you are pointing out. In these cases, we block people from committing,
forcing them to start thinking about if what they are going to commit
is correct. With 1.5.x, developers had to be attentive all the time
anyway. So it's not like there was a regression. Quite the opposite.
We omitted obstructions from the picture so we could focus on getting the tree
conflict feature implemented correctly, in its first iteration, for versioned
nodes in the WC. This alone was a lot of work. For all we know there might
still be problems which we'll only discover post-release as people start
actually using this in production. In fact, fixes for this feature are
still being committed to trunk as we speak (see the commit logs of today
and the last few days).
But you can only do so much in one release cycle.
Subversion does not end with 1.6. We can still improve this further.
You are demanding more than we could deliver for 1.6, which is not a
bad thing to be doing. But if you want faster progress, join the fun!
Received on 2009-02-14 01:21:15 CET