Tom Lord wrote:
[...]
I'd like to mention a few of my thoughts rising from the matter. I
have done very little actual work on subversion myself and cannot
really speak for anyone else but myself.
What you are saying about software development in general does touch
something inside me very deeply. Development on the idea level has
been way too stagnant for a long while. But that is not the subject I
wish to raise here, now.
The Subversion project started out with the goal of making a CVS
replacement - and it has done very well. I can see 1.0 being very near
now. The basic lemma - as sussman has said many times - is that the
CVS model for revision control is indeed a good one. Dropping that
completely away is a huge step to stake - one that the subversion
development team will not take, and should not take.
The point here is that people are used to a system for revision
control - and they want to keep on using it. Bringing something new
out of the sky is just going to get them turn their heads somewhere
else. But it's also that people need to get exposed to the problem -
the problem of collaborating with other people in revision control. In
my opinion, in CVS, people do not really see this as a problem. With
CVS, they have way too many problems with the per-file revisioning and
atomicity and rename support in general, that they think 'cvs diff' is
a pretty neat idea. But after something better comes up - something
that solves the obvious common problems of producing anything at all -
people start to really use these features. They start to produce
patchsets by doing 'svn diff' on two revisions, they start merging
more often between branches, they start to depend on ancestry
sensitive merges. It won't be long until they really run into the
problems of inadequate patch formats, producing clean change-sets and
distributed access. But still today people cannot run into those
problems with CVS, since they are obscured by a larger field of
problems.
But, regardless of this move to better revision control - I personally
still prefer the CVS model for some of my projects. Most of them do
not even have source-code. And a better tool to work with them is
needed, regarless of new revision control methods.
Hmh, I've been going off on a tangent a bit. But what I really wanted
to say comes next.
I don't believe the subversion project will, or should, change their
basic goal for 1.0. But that doesn't mean that the project cannot
incorporate features that will enable it to function otherwise as
well. And the "as well" here is the key word. Subversion _must_ work
as a CVS replacement, with CVS type of semantics in revision
control. If it can work otherwise as well, that is very good - but it
cannot hinder the original model.
What this means in practice is that there's a ton of stuff to do -
that will have to be done in any case in the future - but which will
not break the current operating model of subversion. A common patch
set format which handles metadata properly is really needed - as is
proper ancestor and history handling. Global namespace and distributed
operation can be gotten in as long as it doesn't hurt the normal
stuff. And I think this is what the other subversion developers have
been trying to say, in addition to them having relatively little free
time for anything outside their scope. As long as the current model
can be still be kept - I think the team can be persuaded even into
major schema changes, even though it will probably have to done
through a wall of moaning :-)
So - what can you contribute to subversion as it is _today_, so that
it can still keep operating like it is today, even if the change is
for tomorrow?
This was a bit of a rushed post - but I seem to have the trouble of
the subject fanning out if I think about it too much - so here it is,
without spellchecking ;-)
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 11 14:44:30 2002