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

[Andrew Morton <akpm@zip.com.au>]

Rik van Riel wrote:
> 
> On Thu, 7 Mar 2002, Jonathan A. George wrote:
> 
> > I am considering adding some enhancements to CVS to address deficiencies
> > which adversely affect my productivity.
> 
> > ... I would like to know what the Bitkeeper users consider the minimum
> > acceptable set of improvements that CVS would require for broader
> > acceptance.
> 
> 1) working merges

Yes, cvs is poor at that.  This is a bugfix, not a feature request :)

> 2) atomic checkins of entire patches, fast tags

Yes.  changesets against a *group* of files (ie: a patch) needs
to become a first-class citizen.
 
> 3) graphical 2-way merging tool like bitkeeper has
>    (this might not seem essential to people who have
>    never used it, but it has saved me many many hours)

Current tkdiff is in fact very good at this.  So integration
with that may suit.

The problem I find is that I often want to take (file1+patch) -> file2,
when I don't have file1.  But merge tools want to take (file1|file2) -> file3.
I haven't seen a graphical tool which helps you to wiggle a patch into
a file.

> 4) distributed repositories
> 
> 5) ability to exchange changesets by email

These can probably be in version 2...

Probably the requirements of general developers differ from those
of tree-owners.  The general developer is always working against
the official tree.

This is a bit extreme perhaps but I'm currently working code which
consists of twelve changesets against 100 files.  Many of those
files are changed by multiple changesets.  So two things:

1: If I have two changesets applied to a file, and I make a change to
   that file, which changeset is it to be associated with?

2: The ability to move a set of changes from one changeset into
   another one.  ie: split that damn patch up!

But as a starting point I'd say: changesets as a first-class-concept,
and lots of integration with tkdiff.

-