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--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 15 2002 - 22:00:09 EST