your going to be forcing people to install some other piece of software.
while this might be fine for a lot of people, some won't or can't.
Some IDE's don't have SVN support yet, and some people have to deal with sysadmins who think redhat 5.2 is acceptable work environment to develop with.
I'm -0.5 on the issue overall. I can't see what benefit it will give httpd overall at this stage.
While I can't cast a vote, I'd like to agree with Mr. Holsman and offer a few comments for those that do vote to think about.
I understand that SVN is the bright shiny new toy in the toybox and a lot of 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.
Before deciding on something as important as switching your working, well-known-with-warts-and-all revision control system to a new one there are implementation details beyond just the tool interface that are worthy of consideration. For example, in CVS, every file under revision control is backed by a filesystem object. In SVN all files are managed in a (much 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 2Gb per filesystem object in a repository, you are now *potentially* restricted to 2Gb per repository. Maybe BerkeleyDB works around this. Maybe it doesn't. Maybe you just dont care and you make LFS a server requirement. Its worth investigating. It also has considerable backup and restore consequences. In the current system, if a repository file goes bad, you can restore just that file. With the SVN approach of you happend to get a bad sector in the middle of your repository you may have to restore the entire 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.
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 there perhaps custom keywords such as $Apache$ or the like that would need to be rolled into the local version of SVN? If there are custom keywords *can* they be implemented at the repository server level or would such expansion be taken care of at the client level (which would imply that all clients would need to be patched accordingly)?
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 is there an auditing mechanism in place that you can run to guarantee that all history has been preserved? Historical data is of inestimable value and if there is even the slightest chance that some of it could be lost or become less accessible these are risks that need to be understood and clearly agreed upon as being acceptable losses.
If there are a specific list of problems that frequently hamper developers that such a move would address, it is worth drawing up that list and debating the relative importance of each problem. Moving just because the tool is available is likely to cause some unforseen headaches down the road.
Having said all that, I fully acknowledge that svn is a huge step forwards from cvs in many many ways, but at the end of the day, there is no such thing as a magic bullet, and you will really just be exchanging one set of problems for another.
Just my $0.02.
Kean
