Re: Kernel SCM: When does CVS fall down where it REALLY matters?

["Jonathan A. George" <JGeorge@greshamstorage.com>]

Dave Jones wrote:

>  Old method:
> - diff linux-vanilla linux-dj >dj.diff
> - grepdiff reiser dj.diff | xargs -n1 filterdiff dj.diff -i >reiser.diff
> - copy this file to reiser-1.diff reiser-2.diff with the intention
>   of making each diff have only one 'theme'
> - vi reiser1.diff, chop out unneeded bits
> - repeat for all remaining files
> - check they all apply on top of Linus' latest.
> (If during any of the steps above, Linus puts out a new pre that
>  touches any of the files these patches do, resync, and go back to step #1)
>
>The new method:
> - bk pull
> - bk citool
> - tag reiserfs files in cset
> - hide bits in this delta that don't apply to this csets 'theme' [1]
> - Once I have the grouped together cset, I generate a diff.
> If during any of these steps Linus changes any of these files, I
> bk pull, and with luck, bk does the nasty bits for me, and fires up
> the conflict resolution tool if needbe.
>
This is a great example Dave, and is exactly the kind of feedback that 
free SCM tool developers need.  This is my current list of features CVS 
doesn't have which are important for kernel developers (or me).

1.    Storage of select inode metadata (i.e. link, pipe, dir, owner, ...)
2.    Ability to rename files
3.    Atomic patch set tagging (i.e. global tag patched files)
4.    Advanced merge conflict tool (i.e. tkdiff/gvimdiff like features)
5.    Remote branch repository support
6.    Multi-branch merging and tracking (i.e. merge once)

The first three have been on my personal hit list for a while.  A good 
implementation of 5 & 6 are probably the toughest to do properly, but 
also seem like key elements for kernel developers due to the importance 
of multiple trees.  I'm not really worried about the performance of CVS 
since any problems here can probably be solved by adding some 
administrative meta data for caching and some tweaks to the back end.  
However, it sounds as if Arch and PRCS are pretty interesting, and I 
hope that a couple of people take a look at them to see how close it is 
to suitable.  My respect for BK is certainly been enhanced by this 
discussion, but I still would prefer a free (or failing that GPL) 
license. ;-)

Comments?

--Jonathan--