So, this discussion about atomic renames and why they are/aren't
important, and the follow-on discussion about merge tracking, are
exactly why I didn't propose atomic renames for 1.3 or 1.4 :-).
Locking was big partly because it involved a lot of design discussion.
Atomic renames will be worse, because it isn't just one problem, its
scope remains to be decided. It *sounds* simple, but when you start
to look at the problem, you realize it's not. We've already seen that
happening in this thread, and we haven't even scratched the surface
yet.
Those discussions are important to have! But they should also be a
factor in our release scheduling. We just did a fairly complex,
discussion-laden release; doing another one right afterwards would be
a mistake IMHO.
Although server->client configurations and operation logging will also
require discussion, neither will require as much as atomic renames.
It would be better to grab some of this relatively low-hanging fruit
first, and not trap ourselves into another six-month release cycle for
1.3 and 1.4.
So, this is why I think the original proposal is a good way to go.
And I won't deny that that ordering is also good for CollabNet's
needs. But the reasons it's good for Collabnet are largely the same
as the reasons it's good for the project as a whole: don't try to do N
big releases in a row, grab lower-hanging fruit sooner, and try for a
balance between long-term investments and instant gratification. We
just did a long-term investment, now it's time for some gratification!
Another possibility:
We could start the atomic renames discussion earlier, so that much
more is decided by the time we get to 1.5. Usually my instinct is to
avoid having multiple design discussions going on at once, but a)
that's probably overly conservative, and b) it's only really a problem
when all of the discussions are about things destined for the next
upcoming release, which wouldn't be the case here.
Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 23 22:23:57 2005