size of repository with many branches, vs. git

[Giorgos Keramidas]

On Fri, 11 Apr 2008 12:50:31 +0300, Dov Feldstern <dfeldstern at fastimap.com> wrote:
> Giorgos Keramidas wrote:
>>> Patrick --- perhaps convert could use this information, and only
>>> create a branch from directories which are copies of trunk? Creating
>>> a branch from any other kind of directory would invariably lead to
>>> lots of files being removed/added/moved, which would quickly cause
>>> the kind if bloat I was seeing.
>>
>> There are cases where copying non-trunk Subversion paths makes sense
>> too, i.e.:
>>
>> [1] Initial branch for the 6.x release series
>>
>>     svn copy file:///svnroot/trunk file:///svnroot/branches/release-6.x
>>
>> [2] Some time later: branch for patches/bugfixes of the 6.1 release
>>
>>     svn copy file:///svnroot/branches/release-6.x file:///svnroot/branches/release-6.1
>>
>> [3] Even later: branch for patches/bugfixes of the 6.2 release
>>
>>     svn copy file:///svnroot/branches/release-6.x file:///svnroot/branches/release-6.2
>
> Hmm, you're right, of course... So modify that to "only create a
> branch from directories which are copies of trunk or another branch
> (defined recursively)".  This is probably still doable...?

We may want to cover more bases by: ``only create a branch from
directories which are copies of trunk, another branch, or a tag''.
There's nothing that prevents forking a branch from a specific tag
either:

    svn cp file:///svnroot/tags/release-1.2.3 \
           file:///svnroot/branches/release-1.2

Some projects may be doing that in Subversion to create `release patch'
branches from a well known starting point.