people have worked very hard to make it work, and its good. But at the same time, one should be careful of falling into the "when you have a new hammer everything looks like a nail" trap.
Subversion serves *exactly* the same purpose as CVS. We're not trying anything new or asking that people switch to a different SCM model (like tla).
...smaller) set of filesystem objects as managed by Berkeley DB. This implies fundamental limitations not present in the current system. Think large files. Sure LFS is not likely to be an issue on your servers but it might be. Its worth thinging about. Whereas currently you would be restricted to
thing. Its not a huge deal I know but still, I'm just making sure you consider the issue, even if just to dismiss it as a non-issue.
BDB supports largefiles by default. I suggest you read up on Berkeley DB.
There are lots of people who are running SVN repositories over several GB (including Conectiva, a Linux distro - last we heard they were over 10GB):
<http://subversion.tigris.org/svn-repositories2.html>
Are you sure that things like keyword expansion will work as they currently do? They probably will do but again, it should be carefully considered. Are
We don't use keyword expansion in CVS, but Subversion has support for keyword expansion.
The original proposal stated that full history will be preserved. As I recall from the svn dev list the cvs2svn conversion process has been plagued with difficulties. Are all the issues resolved? If you do make such a move
Yes. Remember, we're not going to delete the CVS repository, only lock it out for future commits. So, if a bug in cvs2svn's conversion is found (unlikely, but possible), we can fix it and re-import.
Please don't try to portray this as a 'snap' decision. We've been planning this out for well over a year now. In fact, before I joined [EMAIL PROTECTED] all those years ago, Roy said that we'd be switching over to Subversion 'soon.' Ha! -- justin
