[Monotone-devel] Re: Monotone and changesets

[Bruce Stephens]

Nathaniel Smith <address@hidden> writes:

[...]

> There's some extra overhead here maybe in requesting contributors to
> not pile their changes on top of each other; but everyone already
> requires the discipline to "make only one change at a time"; if I
> commit two different changes at once in Arch, IIUC it's impossible
> to cherrypick just half of that commit.

That's true.

> Furthermore, the extra information is quite valuable -- if it takes
> several patches to make one logical change, IIUC in Arch the
> maintainer has to figure out "okay, it's patch-7, patch-10, and
> patch-11 that I need to integrate", and bad things happen if they
> make a mistake.  While with Monotone's recommended model, this is
> taken care of for you.  (Of course, in Arch if you're using branches
> properly you're doing the same thing as in Monotone's recommended
> model, right?)

You can do either in Arch.  So you can make a long-lived branch, with
a variety of changes as convenient.  That's subject to risk, I guess
(I've never used Arch in that way), since the branches may get too
different for the changesets to apply cleanly.

It's not as inconvenient as it might seem, since Arch has a number of
ways of getting information about patch revisions.  For example:

% tla revisions -s address@hidden/tla--devo--1.3

base-0
    tag of address@hidden/tla--devo--1.2--patch-115
patch-1
    [LOG PRUNING]
patch-2
    changelog shuffle
patch-3
    fix bug 77 (missing newline in ancestry)
patch-4
    [CLOSE: 81] clean up library-config help message
patch-5
    [CLOSE: 78] error message fixes for commit
patch-6
    [MERGED: address@hidden proftpd fix
patch-7
    error message tweak

Each patch has a one-line summary, as well as a longer log, so that
gives a natural space-efficient way to get information.  With any luck
that gives an easy way to find out which changesets to cherrypick.

[...]