Huh. 10 gigabyte svn repo at work spanning about 40 projects.. Creating branches is virtually instantaneous. It's just a copy which is a free operation (just a link). Curious as to why it would be slow for you.
svn cp https:/ /server/svn/trunk/project/ https:/ /server/svn/branches/project/ticket -m "making a branch here"
svn status, even for an entire repo checkout (which is not common) is also fast.
And yeah, it has virtue of simplicity as well doing very well at narrow and shallow even though I'd love to have mercurial's feature set.
It's also rather good in the "wiki" situation since people can operate on their single files without needing to update, sync and merge.
> Creating branches is virtually instantaneous. It's just a copy which is a free operation (just a link).
Copy is not a "free" operation, but a symlink is close to "free" if you're measuring disk space.
What version SVN are you using? I'm certain that older SVN versions would actually copy the entire project's files, not symlinks but real copies. That would take forever and running out of disk space was a real concern.
An svn copy is just a link. It has always been a "free" operation (and yes, the analogy would be to a symlink).
I'm not aware of any version of svn that behaved the way you described and I've used it for a couple of decades.
I can perhaps imagine a large repo plus a broken svn client requiring checking out unneeded portions of trees to do a copy, but no client I've used works like that.
Hm. Another theory. Perhaps someone who knew nothing about svn and was using TortoiseSVN's Windows file manager integration was doing a Windows file manager copy, then checking that in as a "branch" with the only link being the commit message instead of using svn's copy which is free and properly links content. That would indeed be an expensive operation, and the wrong thing to do.
svn status, even for an entire repo checkout (which is not common) is also fast.
And yeah, it has virtue of simplicity as well doing very well at narrow and shallow even though I'd love to have mercurial's feature set.
It's also rather good in the "wiki" situation since people can operate on their single files without needing to update, sync and merge.
https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs...
A fun rant, even though git has gotten better-ish at large files.