On 25 Feb 2006, at 4:16 PM, Robert Douglass wrote:

For what its worth, I'll be toying with bzr too, having spent time in the radiation radius of hunmonk and jblack. Let's just say they are convincing salespeople.

I'd be more compelled to use bzr if subversion didn't already solve all the problems I had with cvs. BZR doesn't bring enough new to the table to convince me to use it. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

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 -- [ Bèr Kessels | Drupal services www.webschuur.com ]

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? ..chrisxj

Chris Johnson wrote:

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.

As someone who's been using CVS for a long time, I like SVN a lot, and I think it's fair to say that it's CVS Done Right, which I gather was the goal in designing it. bzr has a very similar command set, and if you're using it for fairly centralized development, I don't see any real advantage for using it over SVN. SVN is stable, and it's easier to use over a network than CVS. If that's what you care about, it's definitely SVN over either CVS or BZR.

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.

That's my impression as well.

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. :-)

This is also a concern of mine. I'm also surprised at how difficult it's been to find documentation of very basic things, like how you create your own bazaar-ng repository -- which I'd like to do, if only as an experiment. Anybody have a pointer to a doc??

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?

Here's where I differ with you, since as someone who's relatively new to the community, the decentralized BZR model would have been very helpful to me over the last few months. I'm sure someone has a better coinage than this, but I call it "The Gatekeeper Problem". Any OSS project of any maturity needs quality controls, and one of the best controls is making sure the stuff that gets checked in meets some level of quality, and has an approach that is compatible with the general direction and architecture of the project. This is generally a good thing, and the community definitely benefits from this, whether you have a "benevolent dictator for life" model, or if you have a modularized project where lots of sub-maintainers have "benevolent dictatorship" privileges over relatively small bits of the source base. AFAIK, Drupal uses a hybrid of the two approaches, and generally, it works pretty well, especially if you're a module maintainer for the modules that are important for the work you do. These people are "the gatekeepers" of the project, and they do a very necessary job. But I'm not a module maintainer of most of the modules I use. I'm a working programmer who collaborates with many other programmers, works on projects that go on for months, and does work for groups with multiple programmers. For this kind of work, it's important that my work is in source control in a public repository somewhere, so my collaborators can get at my most recent work easily (and know what *is* the most recent versions of my modules), and so that if the module maintainers decide to merge in my changes, it's easy for them to do so. Patch queues aren't working for me. First, most module maintainers are very busy working programmers themselves, and they of course work on their own schedules, and not mine. So I now have changes in some modules that have been in one module's patch queue or the other for a month and more, And since it is the module owner's perfect right not to accept my patches (benevolent dictatorship, remember), I can't be sure the changes will ever be available there. Again, nothing against the module owners (although some of them have their suspicions about me, I'd guess :) ). They are being totally rational, and they are totally within their rights. But it doesn't solve my problem. Now, I could (and still may) post stuff in my Drupal contribution sandbox, although it feels funny to me to post revisions of someone else's work in the same repository. And I suspect that if people didn't understand why I was doing it, it might upset or offend some people, which is the last thing I need or want to do. Or I could simply establish an SVN repository on my web site and do it that way. The reason I'm considering BZR is that it looks like it would be much easier for people to use the official versions of the modules and then take on parts or all of my additions very easily, since merging stuff between distributed branches is what BZR does best. Assuming that it's reliable enough to use (which you can certainly argue about), it looks like the best solution of my problem. I would just start a private branch of the modules I use, and check into it. If the module maintainer wanted to accept my stuff, great, easy for the module maintainer. But if the maintainer did not want my changes, they would still be available to other people I work with. Cheers, Rob