On Mar 1, 2011, at 07:51, Colin Fraser wrote: > I'm looking to migrate an existing repository from CVS into SVN and I've been > trying to find concrete examples of capacity limits. > > Our workflow is to create private branches for bug fixing, feature > development, RC testing etc so we end up with a lot of branches and tags over > time - CVS is now struggling to support this (time taken to branch is hours). > I've seen plenty examples given about the physical size or number of commits > supported in an SVN repository, but nothing about the number of branches and > tags that can be supported. > > Basically I'm concerned about performance degradation over time if we > continue to create many branches. The numbers I'm talking about are around > 2000 branches and 3000 tags, increasing by about 500 per year. > > Any information or links appreciated.
There isn't a limit, that I'm aware of. One of the big advances in Subversion over CVS is that branches and tags are implemented differently, and can be created in a short more or less constant amount of time. In Subversion, they're just ordinary directories, and there's not a limit on that in Subversion either. http://svnbook.red-bean.com/nightly/en/svn.forcvs.branches-and-tags.html Having thousands of items in a directory that's checked out can be problematic, but you presumably won't be trying to check out all thousands of your tags at once, so that should be fine. I also wouldn't expect you to keep those thousands of branches around. Feature branches -- those created for bugfixes or new features -- should be deleted (or at least moved to an archive directory) once they've been merged into the trunk. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature
