Re: [Gnu-arch-users] Re: arch/subversion comparison question

[Tom Lord]

    > From: Miles Bader <address@hidden>

    > On Fri, Mar 12, 2004 at 05:11:23PM +0530, Amit shah wrote:
    > > Basically, darcs allows you to establish (or rather, itself establishes)
    > > relationships between patches

    > How on earth does darcs know what dependency relationships exist between
    > patches?!?  Even the human making the changes often doesn't have a very
    > good idea of what they are!

The approach we're talking about re Cehteh's RFC is to permit explicit 
and mutable declarations of the relationships by users.

One use for this that would help current practices in the arch project
concerns some people's integration branches.   They'll mostly wind up
with a list of revisions that partitions into continuous sublists each
of which constitutes a "clean isolated change" -- but rarely perfectly
so.   Some bug will be found late, for example, and then you wind up
with changes on the integration branch that are slightly "out of
order".

In addition to that, the whole point of an integration branch is a
convenient review, testing, and integration area that then goes
through a second stage of review before hitting mainline.  It's not
that uncommon that I'll decide I want some of the changes on an
integration branch, but not all of them -- so I wind up
cherry-picking.

In practice, this involves me sending mail to the integration manager
asking for a list of revisions categorized into isolated changes then
using that during cherry-picking.    It would save those round-trips
of that information was embedded in the version itself -- which is
what the RFC proposes an interface for.

Obviously it has other uses, too.  Such declarations can both trigger
and record results of things such as automatic testing or
relationships to an external database such as an issue tracker.

It may sound horribly awkward to have to declare all these things by
hand but Cehteh's idea of "inheretence" makes that not so:

Suppose there are 4 feature branches in the world.   The integration
keeper can ask the maintainers of those to make sure they're
appropriately labeled.   That can be done even ex post facto and, due
to inheretence, it only has to be done once and "sticks" to any future
revisions in the feature branch.

During merging into integration, the feature labels are automatically
propogated to the integration branch in a non-inheriting form.   So
the integration manager need not label anything himself if the feature
branches are appropriately labeled.

(I can imagine adding convenience features, to, such as automatically
treating certain revisions as labeled by some string derived from
their branch name.)

-t