[development] Is contributions/modules/ mirrored for bazaar-ng?

Chris Johnson chris at tinpixel.com
Sat Feb 25 17:51:59 UTC 2006

Bèr Kessels wrote:
> Op zaterdag 25 februari 2006 15:31, schreef Adrian Rossouw:
>>> BZR doesn't bring enough new to the table to convince me to use it.
>> That said. I did promise i'd try it before bitching and moaning about  
>> it.
> I am confident that you will at least be impressed :). It is not so much the 
> commands that are sipler (which is the only real improvement of SVN over 
> CVS).But the whole revolutionary idea and logistics of the bzr. 
> comparing BZR with SVN and SVN with CVS is like comparing A CMS with BASH and 
> BASH/VI with DOS/EDIT for content and file management. BASH solves loads of 
> issues with DOS. But both are still sharing the concept of the CLI. A CMS, on 
> the web is just so utterly different, but it also manages content and files. 
> Bèr

I beg to differ.

The 3 different version control systems I've used most recently are CVS, BZR 
and SVN.

I've used CVS long enough that I'm very comfortable with manipulating the 
repository files directly, which one must do if one wants to move 
subdirectories around and preserve the change histories.  That is probably 
CVS's biggest failing.

I also know how to make CVS do the parallel, personal repository trick that 
impresses most people with BZR.  BZR even impressed me with that, because even 
though CVS *can* do it, it is a *lot of work* in CVS whereas in BZR it is 
typing 3 fairly simple commands.

I've used BZR with Chad (hunmonk) in helping him out with his undo/trashcan 
modifications to core.

And at my full time job, we just converted our CVS repo to SVN last month, and 
so I use SVN every day now.

BZR is not in any way an order of magnitude better than SVN or CVS.  Saying 
BZR is like a CMS, and SVN & CVS are like command line tools makes no sense. 
For basic everyday operations, they are all roughly equivalent in what is 
typed at the command line.

Where BZR makes parallel development in separate, but periodically 
synchronized repositories much easier than CVS, it falls on its face with 
having robust, complete, bug-free code.  BZR is missing useful minor features 
available in CVS for reporting status and history, for example.  BZR sometimes 
crashes due to bugs in code.  (The last time CVS crashed was before you 
learned to read and write.  :-)

I can't draw as accurate a comparison with SVN, as I have not pushed its 
boundaries yet.  So far, so good -- except that it's more verbose than CVS (as 
is BZR), and not using a simple flat-file repository structure like CVS, one 
cannot easily grep past versions to find things.  Still, SVN offers 
significant advantages over CVS, although "simpler commands" is *not* one of 
them, despite what Bèr wrote.  The day to day SVN commands are exactly the 
same as the day to day CVS commands.

 From a user's point of view, SVN's core advantages over CVS are:

# Directories, renames, and file meta-data are versioned.
Lack of these features is one of the most common complaints against CVS. 
Subversion versions not only file contents and file existence, but also 
directories, copies, and renames. It also allows arbitrary metadata 
("properties") to be versioned along with any file or directory, and provides 
a mechanism for versioning the `execute' permission flag on files.

# Commits are truly atomic.
No part of a commit takes effect until the entire commit has succeeded. 
Revision numbers are per-commit, not per-file; log messages are attached to 
the revision, not stored redundantly as in CVS.

So BZR would probably (have not investigated, but from the SVN docs it 
appears) excel above SVN in the same primary way it excels above CVS:  it 
makes doing parallel repository development easier.  But, as has been shown, 
one can do that with Drupal without converting Drupal's repository.  People 
have already done it.  Would this advantage be worth changing Drupal's core 
and contrib repos?  Or are the downsides of going completely to BZR too big?


More information about the development mailing list