[cvsnt] Re: cvsnt status

Tony Hoyle tmh at nodomain.org
Tue Jul 15 10:20:04 BST 2003

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.

Ori Berger wrote:

> Don't know if that's still the case, but it used to have a rather
> small artificial limit on table sizes (4GB or something). While this
> is sufficient for most source repositories, it might be insufficient
> if you regularly commit binary files that are over 1-meg in size.

That's unlikely, though... cvs doesn't scale for really large files.. it
won't fail, but you'll end up with checkouts taking stupidly long lengths
of time (someone here committed a 137MB file and it was taking roughly 5
minutes to process that single file...  admittedly on a slightly
underpowered server).

msde2000 is OK for most purposes and a lot of installations already have it
(whether they realise it or not!).  There's no particular reason why there
couldn't be an access backend too but I don't think I'd want to trust a
repository to it.  SQL Server is just msde with knobs on...  

mysql/pgsql are quite easy to add (and will be required for the unix port
I'd expect).

I could also write my own transactioning backend, but that'd require a bit
of research before I could get it right.... might do it though just to see
how hard it is :)

The way the development code is structured there's no reason why any/all of
these options (plus the original RCS backend) couldn't be supported in the
same binary.  I'm deliberately only using simple select/update commands,
plus transactioning (which is the real win here... no read locks required
and multiple commits can overlap provided they don't affect the same
files), and automatic rollback.


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook