I don't think we should be targeting the Linux kernel's
current developer model.
[....]
I've written a document about this
http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot
Is your document a "marketing" tool or a quasi-academic tool? In
other words, should I read it presuming it is meant to persuade by
reason (quasi-academic)? or should I expect otherwise? I don't mean
that to be a sarcastic or rhetorical question, though I know it can
easily be construed as such.
The topics addressed in your document are among the kinds of positions
you are invited to come and present and discuss on arch-users, for
your own benefit, as well as for the benefit of others. Your document
is authored with the presumption that you have some deep insights into
software development and its implications for revision control. In
spite of the project-specific list name -- such insights are what we
invite you to discuss and compare and contrast with the insights of
others on arch-users.
I have read your document. It is predicated on (a) your assertion
that there is a deep, objective dichotomy in development models, with
Linux kernel on one side, and projects such as the BSDs, Mozilla, and
Apache on the other and (b) your arguments that the two sides of this
dichotomy imply very different revision control requirements.
I think that the arguments in your document are quite problematic (to
put it mildly) -- but I also wonder if, if you were challenged to find
better arguments, your conclusions would stand -- or whether (what I
think is more likely) you'd realize that svn can be simultaneously
greatly simplified, and made more powerful, by learning lessons from
the arch world which would show you there is not such dichotomy, and
no such variations in requirements.
I must add, also, that the _original_ goals of Subversion 1.0, which
are _still_ goals for Subversion post-1.0, are somewhat contrary to
the position argued in your document. Specifically, that which you
call "pyramid management" is not really, as you suggest in your
document, equivalent to having a single integrator or distributed
repositories -- rather, it is the least problematic use of
history-sensative merging among branches, which was, as I recall, in
addition to transactions and true renaming, one of the key goals for
svn in the first place. We can help you reach those original goals
"faster, cheaper, better" -- and go beyond them as well.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 17 01:33:04 2003