Capacity limit on Branches and Tags in SVN
Colin Fraser
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.
Thanks,
Colin Fraser
This electronic message (whether email or facsimile) and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If you are not the designated recipient, please notify the sender immediately and destroy this message. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this message are the personal views of the author.
Level Four Software Ltd. Registered in Scotland No. SC157659. Registered office: Level Four House, Pitreavie Court, Dunfermline, Fife, KY11 8UU, UK
Level Four Americas LLC. 5960 Fairview Road, Suite 400, Charlotte, NC 28210, USA
Level Four (Middle East). Al Thuraya Tower 1, 2nd Floor - Office 209, Dubai Internet City, P.O. Box 500274, Dubai, U.A.E
Andy Levy
> Hi,
>
> 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.
Subversion branches and tags are just specially-named copies (you
don't even have to call them "branch" or "tag" if you don't want).
Copies in Subversion are cheap - each will take maybe 1KB of space.
See http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html
You shouldn't have the same trouble in SVN as you've had in CVS.
Ryan Schmidt
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.