[os-infrastructure] Other source code control systems - WAS: Model discussion boiled dry(er)

[Chris Clark]

On 6/26/2008 4:17 AM, Jay Hankinson wrote:
> Both mercurial (http://www.selenic.com/mercurial/wiki/) and bazzar 
> (http://bazaar-vcs.org/) are excellent open source scm systems.  
> Mercurial is used by rPath Linux and JasperSoft and bazaar has 
> recently been adopted by MySQL for managing all they're code. Their 
> tool requirements will be at least as demanding as ours and they're 
> communities are far larger.
> I would encourage you to take a look at what these products offer 
> interms of feature and methods of working to give you an idea how how 
> far behind piccolo really is. (Automatic gatekeeper support for one)
> At the moment the only outstanding issue as far as missing features 
> are concerned is the label functionality that. I for one think that we 
> should consider reviewing some of our processes before getting too 
> hung up on single pieces of piccolo functionality. Even in the event 
> we decide we can't live with some feature (p label for instance) both 
> mercurial and bazzar are python based and easily extensible.
> I am playing with both of these tools at the moment and hope to share 
> my findings (and hopefully solutions) soon.

I'd be interested in the findings on the distributed systems, 
distributed systems have a good merging implementation and Ingres needs 
good cross integration support! From my brief contact with both hg and bzr:

* they both suck big time at handling different newlines, the 3rd party 
extensions for dealing with this doesn't really work well.
* sparse checkouts are not yet available, if you do a check out you get 
ALL the history
* revision numbers in hg are cryptic, how do you know if you have an 
older version of a file just from the rev numbers, see 
http://selenic.com/repo/hg-stable for a live repository (there is a nice 
blob posting on this 
http://jameswestby.net/weblog/bzr/01-revision-numbers.html where they 
talk about bzr numbers)
* you need python on the platform where you want code to reside, bzr may 
be runnable with the new (JVM based) Jython 2.5, hg is not due to 
(simple) C extensions (these are present for performance, so could 
probably be re-implemented in java or even jini)


The first 2 issues will be addressed, rev numbers in hg are less likely 
be chaged. The Python requirement is currently a show-stopper for VMS 
and mainframe. bzr also has a central server mode which we would find 
very similar to our current approach with the benefits of distributed 
scs too. The central server mode really is the focus for Canonical, bzr 
is rather attractive.

RE labels and build practices -- our main use of labels is to have 
stable known working code (e.g. do not include headrevs, we know it is 
broken or we've not yet QA'd it properly), if we were to rollback bad 
changes back as they are found (bzr and hg make this trivial, piccolo 
makes this manual) we could simple use change (in hg) or rev (in bzr) 
numbers (tags in those are simply names that map to the change/rev 
number). I've obviously simplified the situation grossly but changes to 
practices could be very beneficial.

Using a sync mechanism does mean we don't have to migrate support (and 
GA releases) to a new system just yet so we can afford to experiment 
with the sync and see how that works. Using subversion also means we can 
experiment with bzr 
(http://bazaar-vcs.org/BzrForeignBranches/Subversion) today.

A good small scale experiment for bzr would be to import the MediaWiki 
(and/or phpBB) code. My understanding is that neither mediawiki or phpBB 
are interested in our Ingrs changes (at the moment). Using a distributed 
scs like bzr would make it easier to contribute back our changes if that 
ever changes, right now we have forks, bzr would make those forks branches.

My findings are that most scs's have everything that piccolo does (and 
more) with the following exceptions:

    * decent cross integration support is not that common (some other
      scs do manage this though)
    * labels - tags often have other behaviors than a simple snap shot
      of arbitrary file versions
    * configurable maps - svn can sort of do this with LOTS of futzing
    * built in bug database support, this is usually handled with a
      dedicated bug (or issue tracking) system that hooks into the scs.
      Piccolo is currently wedded to bugs.

We absolutely need decent cross integrations, the other requirements 
could be handled by engineering/build/procedure changes.

I'm not sure we are really ready to talk about which new source code 
control system we should use. The discussions on the model are more 
important at the moment.

Chris