I like SVN a lot - and for a new project probably I would choose it if there is a choice - sf.net or other places are cvs only. But I don't think all the pain for switching tomcat is justified, and switching few repositories but not others is even worse.
Unless we're going to do major reorganization of the code ( move directories around ) or we start some complex branches, or we have any other need where SVN is much better than CVS - I would say it's better for everyone to stick with the stable environment.
Costin
Henri Yandell wrote:
I've not heard anything about it being mandatory yet, but the numbers speak for themselves.
The www.apache.org site has 24 coding projects. There are 22 projects listed on the svn.apache.org/viewcvs.cgi page. 2 of those are dead, so 20 out of 24 ASF projects have an svn presence of some kind.
The people still left with readable CVS modules are:
mod_perl ant 2/3rds of jakarta possibly gump (though they have an svn module too) apache conference most of xml logging half of web services
So I assume at some point there'll be pressure to turn off the CVS server.
On the command line, svn is pretty much the same as cvs. Some bits are faster, some slower. There are various improved features (http://subversion.tigris.org/ lists them) that people have been asking for for ages with CVS.
Habit-wise, the only differences I've hit are:
1) you checkout from a url, not from a cvs-root and a path. 2) tagging/branching is done by copying a directory revision (really creating a symlink-style thing in the database) and isn't applied to every file individually.
Tool-wise, Subclipse is an Eclipse plugin that seems to work fine for standard development (checkout, update, diff, commit). I'm unsure whether you can create tags/branches using it as I always do that on the command line, be it cvs or svn. IntelliJ has a plugin and the next version will have it built in. TortoiseSvn is spoken well of, and I can vouch for svn on linux/OS X, I've had no problems in the last year of use.
Docs are docs :) Yep, they'll need updating.
Build scripts. Do you have scripts that check modules out of cvs? If so I imagine the ant support for svn might be a big deal. Unsure what it's like.
Hen
On Thu, 03 Feb 2005 21:32:41 -0800, Costin Manolache <[EMAIL PROTECTED]> wrote:
Is this mandatory ? I suspect there'll be a lot of build script/doc/habits/tool changes involved. CVS is working reasonably well at the moment, and a lot of tools have (finally) very good support for it.
Costin
Henri Yandell wrote:
Just wondering if the Tomcat community have any thoughts on a migration to Subversion?
The process seems pretty easy, though Tomcat may be more complicated than the usual CVS module. Infra have the process documented at:
http://www.apache.org/dev/cvs2svn.html
The Jakarta status is in the wiki at:
http://wiki.apache.org/jakarta/Migrating_20to_20Subversion
The aim would be for all the tomcat modules to migrate into asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level structure to the system, within that though the Tomcat community are free to choose whatever strategy fits.
I've intentionally left Tomcat until last to nudge about this so as to build up some experience within Jakarta of dealing with SVN as users and as a migration. Some of you are probably already getting to grips with svn following the Commons migration.
Just to provide the context for this, the Infra group are looking to move from CVS to SVN in the long term and Jakarta were far and away the main laggards in this. In the last month or so, a third of Jakarta has moved over, so that's now improving.
Another question is whether the Tomcat community have any svn expertise in terms of planning svn strategies, or whether we should try to find some other committers to offer opinions.
Thanks,
Hen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
