Moving Away From CVS: A Vote

[Bill Barry]

Max Kanat-Alexander wrote:
> On 09/05/2009 03:43 PM, Bill Barry wrote:
>> There is significant fear that bazaar will break compatibility in
>> upgrades (it has already done so before).
>
>     The fear is unfounded. Bazaar has never actually *broken 
> compatibility* in its upgrades--at least not that I recall since 1.0. 
> However, if administrators of bzr servers choose to convert their 
> repositories to a format that older versions of Bazaar don't support, 
> then it's true that older versions of Bazaar can no longer access 
> those repositories.
I seem to recall some dirstate problem that we had to change how our 
server was working because we couldn't push to it. A new version came 
out about a week after we started evaluating bazaar and we decided to 
upgrade and found that we couldn't push to it. I think it was 1.13 or 
something like that. We gave up pretty quickly after that.
>
>     There would probably be a decision made when we switch to bzr what 
> repository format we were going to use, and then we'd stick with it 
> until such a time as all reasonably available versions of bzr 
> supported a newer repository format (most likely several years). Also, 
> it's looking like the 2a format may indeed be the last word in 
> formats--we'll see. At the least, the packs format is good enough for 
> what we do with Bugzilla, so we may not ever have to change.
>
>> * Bzr has a new release every month because it finds major deficiencies
>> every month.
>
>     Not really. Read the release notes and see.
Every release (and there has been almost 1 a month for the past 2 years) 
seems to fix at least a dozen bugs. How exactly does there happen to be 
a new bug fixed every other day on average? How do that many bugs get in 
the code in the first place? The only ways I can think of are either 
poor coding or hastily done work (which then gets fixed in some 
subsequent release; as paid developers on a project from a company with 
an agenda).

Wasn't it you that wrote the post about sucking less every release?
 
>
> > It also doesn't have minor releases
>
>     Not true, it's had some minor releases. See the release notes. 
> There was a 1.6.1, as an example.
I am sorry, I was wrong there.
>
>> * The mercurial commands are not significantly different than CVS or 
>> SVN.
>
>     Except that last time I checked, Mercurial lacks built-in support 
> for bound branches--the fundamental CVS/SVN workflow (that you commit 
> back to the branch you checked out from with a "commit" command).
No it doesn't have bound branches; I'll give you that too. I don't think 
it would be that difficult to write as an extension. I did write an 
auto-push extension which would function just like bound mode in all 
cases except for when pushing would first require a merge, but the 
repository shouldn't be deciding when to merge. That should be a user 
decision (in Mercurial you may instead want to rebase for instance).

My bound mode extension can be found here: 
https://bitbucket.org/Bill_Barry/boundmode/

In bound mode the centralized workflow would be:
setup:
1. hg clone path
2. hg bind path

daily use:
3. hg pull --update
4. do work
5. hg ci

if ci fails to push (push may be aborted if there already exists a head 
on the central which you don't have)
3. hg pull --update
4. do work
5. hg ci (fails to push)

6. hg pull --rebase
7. hg push

or

6. hg pull
7. hg merge
8. hg ci

or

6. hg fetch
7. hg push

or

6. hg push --force

or any number of other options. The point being that Mercurial shouldn't 
do any magic like automatic merges (which is why fetch is in an 
extension and not in the core by default). But there isn't anything that 
says I couldn't write an extension that does this just like Bazaar does 
(and in fact it would be a fairly simple extension come to think of it; 
simply a push/pull/merge/commit loop until it succeeds).
>
>> As far as superiority: last I checked over 90% of the commits to Bzr
>> were from 2 or 3 people employed by Canonical. There literally was not a
>> developer community.
>
>     Here's the current list of top contributors to bzr:
>
>     https://launchpad.net/bazaar/+topcontributors
>
>     (Looking at the "Bazaar Branches" section will limit it to just 
> code contributors.)

That has changed considerably since we last looked at it over in the 
Mercurial list:
http://www.selenic.com/pipermail/mercurial/2009-January/023261.html

>
>> see a testopia repository
>> that keeps up to date with the changes as they happen).
>
>     That would depend more upon somebody committing development 
> resources to Testopia than a VCS switch, although switching to a DVCS 
> would certainly have some advantages. I agree it would be nice, 
> though. :-)
It will be much easier to maintain a fork than it currently is to 
maintain a single giant patch. I pity what Greg has to go through each 
time he attempts to upgrade Testopia. That is a lot of work (which 
wouldn't be nearly so difficult if it was easier to keep up with the 
changes). His latest news was a bit unsettling as far as the future for 
Testopia goes.