[darcs-users] Re: [BK] upgrade will be needed

Andrea Arcangeli andrea at suse.de
Tue Feb 22 15:01:38 UTC 2005


On Tue, Feb 22, 2005 at 03:20:52PM +0100, zander at kde.org wrote:
> On Tue, Feb 22, 2005 at 03:05:27PM +0100, Andrea Arcangeli wrote:
> > anyway what I normally ask is related to the history of a single file,
> > so having all modification of the same file in one palce is more
> > efficient for that too.
> 
> You do?  Wierd;  most people I know use their SCM to do revision
> management.  You know; to record changes and to distribute them to others.

I don't use it for that. I agree a patch per file is an efficient way to
distribute the code to others.

> After patch management comes conflict management.
> For some users (only the repository managers, mostly) the annotate like
> features are usefull.  But not for the majority of users using an SCM.

The really useful thing of a SCM compared to plain patches to me is that
when I get a bugreport happening in 2.6.11 and doesn't happen in 2.6.5, I
can ask the SCM to show me all patchsets affecting the file where the
crash happened (or the whole subsystem, linux/mm won't clobber my eyes
with all other subsystems). In the kernel there are tons of subsystem
and they're all developed at the same time.  The major feature of a SCM
is that it can filter out the patchsets that aren't relevant to the fs
that I'm debugging.

Diffing the single file between 2.6.5 to 2.6.11 doesn't remotely show
the same great deal of information that you get with cvsps -f. and most
important if I can extract the changesets affecting mm/memory.c it gets
very easy to backout a single changeset too, something I can't do with a
plain diff of the two files or I'd get compiler failures in the other
part of the patchset that I didn't backout.

If it wasn't for this, I almost wouldn't need a SCM. I've enough
automation already at the patch level to solve the distribution and
record of changes and even the reject handling. But those are monolithic
big patches not useful if you need to debug something or watch what
other people did on your code because it's not obvious by reading the
latest revision.

> Well, first thing to learn in any design is that you are not your user.

I just need a tool that works fast for me, cvsps has been the closest to
what I need (except it's readonly and not distributed, so I can't use it
for submission and patch distribution etc..).




More information about the darcs-users mailing list