[cvsnt] Re: CVSNT and Subversion comparison

[Tony Hoyle]

Gerhard Fiedler wrote:

> 
> Neither do I, but I'm seriously considering it. The main reason for that is
> that I'm slowly losing trust in the development process of cvsnt. Binaries
> for previous stable builds are not available anymore (so you need to keep

They're in the archive.

Disk space limits mean I can't keep anything before 2.0.58d at the 
moment, but that's 7 months old!

> your own copies around), there's no publicly available bug database (so you
> need to keep your own log, extracted from the mailing list about what works
> and what doesn't in every stable build you may consider for updating),

In general cvsnt develoment has been very stable - the bug list was 90% 
installation problems and old versions and had frankly become a waste of 
time.  The list is a much better place for it as the simple stuff can be 
filtered and I can concentrate on the real bugs.

Most bugs are found pre-release.  Any extra ones are found usually 
within a few days of the initial release and fixed (which is why I often 
say don't upgrade immediately).

All stable releases are released with zero known bugs, unless noted (for 
example rename isn't worth fixing as it's being gutted and rewritten in 
the development branch).

> there have been some showstopper bugs in releases called stable ("&" in
> file names messed up the meta files), and so on... It seems cvsnt is in a

There have always been exceptions (it used to be '+').  Also, that bug 
was fixed in under 24 hours.

It's in the nature of opensource that the things that get fixed and 
tested first are the things that affect the main developers and 
contributors.  Sometimes that means something you're using isn't used by 
any of the developers.

If something breaks you have 3 choices (and this applies to subversion 
as much as cvsnt or any other community supported project)

1. Keep using what works.  There are still people on 2.0.1 and if that 
works for them that's fine.
2. Send in patches/fix it yourself.  Not open to everyone, of course, 
but a high proportion of cvsnt users are technically literate and so 
could do this.
3. Pay someone to fix it - in the cvsnt case you'd have a fixed/working 
tested version within 48 hours.

> constant flow, fixing some bugs while introducing others, and there's never
> a stable point where you can take a build and deploy it with confidence. By

That's what the stable build is for.  2.5.01 works fine for nearly 
everybody.  The idea of a completely bug free release is fiction - *no* 
development process will give you that, which is why when upgrading any 
application that's critical it should be sandboxed on a test server 
first before being rolled out.

The first proper service release for 2.5.01 is almost ready, and should 
be done this week.

Looking ahead, 2.5.02 is first step in the long term plan, which will 
ultimately become the cvsnt enterprise server.  That's the kind of 
project that marketing like to make powerpoint presentations about...

My own opinion is that the only version control system really doing 
anything innovative at the moment is Arch.  If I was starting from 
scratch today I'd start with something similar to that... everyone's 
just playing at the edges with version control - there are few that 
understand the potential.*

Tony

* TBH I'd love to go off in a different direction and start again with a 
substantially new codebase... jump directly from A to F rather than have 
to go through B,C,D,E.  Real innovation takes too long though...