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.
-
-
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/