I seem to recall that it stores a local copy of the repo data to speed up diffing, this won't be a huge issue unless you store several gigabytes in your repository. You can however use a native svn protocol and this should alleviate the issue, we did not test this at my old company.Īnother issue that is often ignored is storage space, we found that subversion did use several times as much storage locally as CVS. This is almost certainly due to using either http or ssh to transmit file data, compared to the native csv pserver, however since it is so easy to setup svn over ssh or webdav people tend not to think about the protocol overhead. When we swapped from CVS to Subversion, the speed of checking out the repo decreased from one hour to four or five hours. When I was working for a game company we had a few directories containing hundreds of tiny files, and other directories that contained a few hundred meg files. However you should watch out for resource issues. Subversion is probably the right choice, but you must do your homework to get the best results. However, you would be remiss not to at least consider what DVCS's have to offer (Git, Hg, Bzr) or if your budget allows there are commercial tools with excellent reputations (Accurev, Perforce). Merging in subversion is still way harder than it needs to be. (While Git submodules have their place, too, obviously. Ankh SVN provides a very good integration with Visual Studio - almost on par with TFS provided you use VS 2005 or more recent. With modular code, this can be quite nice compared to Git submodules. If you are working alone and want some kind of version control easy to use, then use Subversion.It works great on Windows, setting up the repository is one right click in an empty with Tortoise SVN. With Git the whole repository is a unit, you can get only all or nothing. 1.5 has taken steps to address both of these, but there is still room for improvement. One benefit of Subversion over Git can be that Subversion allows checking out sub-trees only. Merging and mirroring were almost non-existent (well assistance for) pre 1.5. Subversion just uses the username for each commit, while Git stores both a real name and an email address. Else you create a world of hurt for future generations, let alone any tools that need to grok your repo. If you want to make a copy of your code, you have to literally copy/paste it. Subversion's use of convention rather than configuration means that you need to think about your repositories structure in advance and ensure that everyone adheres to it. With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. In addition to losing some of the benefits of real branching and tagging (mentioned in other comments) the biggest problem it creates is that if makes it very easy to screw up. The biggest by far is that Branches and Tags are not first class citizens in svn, they are just directories that adhere to a convention. good remote options http/https/svn vs pserver.Subversion has some substantial wins over CVS:
0 Comments
Leave a Reply. |