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. Tony