On Sun, 30 Oct 2005, Daniel Berlin wrote:

> > I fail to see any reason for this. When you don't need a file anymore, you
> > delete it. When you don't need a directory anymore, you delete it. I can't 
> > see
> > why it should be any different for branches. Deleting a branch makes life
> > easier for people looking for branches, reduce the noise, and makes the
> > repository cleaner.
> 
> Yeah. personally, i'd like to remove them too.
> 
> You can always see them with the [EMAIL PROTECTED] syntax
> 
> ie
> 
> svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]

Which requires remembering an arbitrary revision number (i.e., making life 
*harder* not *easier* for people looking for that branch) rather than a 
more meaningful branch name.  Naming things should allow one to get away 
from such arbitrary numbers.

Abstractly, the history where a branch has been merged into mainline is

mainline -------------------------------------------- current mainline
          \              /
           \            /
           branch-------

(where the branch is ancestral to the current mainline, and logically 
branch-of-today is a hard link to mainline-of-tofay), not

mainline --------------------------------------------- current mainline
          \
           \
            branch------dead

and while version control doesn't effectively represent the first form 
(multiple versions at the same time being ancestral to the same current 
version), I don't think tricks with revision numbers should be needed to 
see the ancestry of mainline.

In order to avoid referencing arbitrary revision numbers, you might create 
a naming scheme by which you assign symbolic names to "the last version of 
branch X".  (For a similar use, I might find it useful to tag 
trunk/gcc/@42778, the last version before *.texi were moved to doc/, for 
more convenient access to the pre-move logs - the issue of seeing ancestry 
of mainline more conveniently applies just as much to files renamed in CVS 
as it does to bifurcated history caused by branches.)  Such naming of a 
particular revision number for more memorable access to its history is of 
course just a cheap copy with history, which is what you get if you move 
the branch to branches/closed, which is back where we started.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    [EMAIL PROTECTED] (personal mail)
    [EMAIL PROTECTED] (CodeSourcery mail)
    [EMAIL PROTECTED] (Bugzilla assignments and CCs)

Reply via email to