[mnet-devel] Subversion vs DARCS

Zooko zooko at zooko.com
Mon Jul 7 22:43:02 BST 2003


Reading the message I just posted, I realized there's a deeper, almost 
philosophical issue here.

Throughout the life of Mojo Nation, and the life of Mnet, I've followed the 
philosophy of "evolution, not revolution".

There have been hundreds -- *literally* hundreds -- of changes to the 
protocol, and every single new version has been backwards compatible with many 
of the most recent old versions, allowing users to gradually upgrade while 
retaining continuous compatibility.

Likewise, a year ago there were perhaps *thousands* of functions and tens of 
thousands of lines of code in the codebase which existed solely for backwards 
compatibility, either with old peers or with "legacy" code elsewhere in the 
codebase.

(We've done a ton of cleanups over the last year or two, updating the legacy 
code so that it no longer does things the old way, and then deleting the old 
code.  Nonetheless, I wouldn't be surprised if there are still hundreds of 
functions and thousands of lines of code like this.  Accumulated cruft.)

And in terms of the actual architecture of the network, although there have been
lots of different architectural changes over the years, each one has been 
backwards-compatible and has been experimented with carefully and incrementally.

This was a grand experiment in how to develop a complex, distributed system!  

It allowed us to have working code and a running network at all times from 
antiquity until a couple of weeks ago.  (Minus the Great Slashdotting of 
October 2000, the disappearance of the AZI Meta Tracker, and perhaps other 
smaller outages.)

It helped us explore the design space thoroughly, trying out hundreds of 
variations of the ideas.

But I'm tired of it.

I'm no longer interested in making all the changes to HEAD be incremental 
changes, because that either (a) prevents us from reaching interesting new 
parts of the design space, because there isn't any incremental path from here 
to there, or (b) makes us take longer to get there, because it takes a lot 
longer to plan out a path so that every CVS commit is backwards compatible and 
monotonically improving than it does to just nuke the old code en masse and 
write exactly what you want in the new code.

So, although we've mentioned several times that changes to the HEAD branch 
ought to be stable and monotonically improving, they ought *not* to be 
incremental!  The guarantee I offer is:

(a) today's HEAD is at least as functional and at least as bug free as 
    yesterday's HEAD, where these things are measured by unit tests and the 
    basic "fiddle with it and see" manual tests, and

(b) anything that gets committed to HEAD has been tested and is considered 
    "pretty stable".

However, I absolutely do *not* offer that:

(c) the architecture, design, ideas, algorithms, code, etc. in today's HEAD 
    are an incremental variation of the ideas from yesterday's HEAD,

(d) anything that gets committed to HEAD has been thoroughly tested and is 
    ready to be distributed to millions of end users.

Of course, there is still a huge need for evolutionary development in addition 
to revolutionary development!  We need evolutionary development so that non-
disruptive features can be added.  There are lots of non-disruptive features 
that we want, and we want them as soon as possible.  We need evolutionary 
development to debug and to improve behavior, and to explore parts of the 
design space that are close enough to the current position that we can explore 
them in a non-disruptive fashion.  We absolutely need evolutionary development 
in order to prepare package releases that are stable, performant, have good 
user interface, and interoperate well with other versions that are out there.

So in my new philosophy, neither evolutionary nor revolutionary development 
will be allowed to have the upper hand.  Each kind is essential, and each kind 
is going to go on *in parallel* with the other kind, at all times.  That's why 
I think that getting a good policy and/or tool to facilitate branch management 
is so important.

Regards,

Zooko

http://zooko.com/
         ^-- under re-construction: some new stuff, some broken links



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel




More information about the Mnet-devel mailing list