Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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...