Re: [Monotone-devel] Re: How will policy branches work?

[Nuno Lucas]

On Feb 8, 2008 12:22 PM, Markus Schiltknecht <address@hidden> wrote:
> Nuno Lucas wrote:
> Well, as long as no single commit spans several modules, you should
> probably use separate branches per module anyway.

In this case you could say they are modules, but it could be a single
file on the source tree, with no clear separation between it and other
source files. You can't have a branch per source file (you could but
makes no sense).

> > Probably this will be solved when monotone gets a proper "cherry pick"
> > system. It would then be possible to "pluck" some group of revisions
> > (that could be restricted by path) and retain history.
>
> I'm not exactly sure what you have in mind for being a "proper cherry
> pick" thing.

For me "cherry picking" is just what pluck does, but with an added
"unpluck" option.
That way you can try different patches, but have the option of
"un-applying" them, for example, while chasing some regression bug.

This can be done outside the DAG, with some list of changesets on the
_MTN dir. You could apply/un-apply a number of "pluck like" changesets
to the workspace and the information about the used changesets saved
somewhere on _MTN.

An extreme example of "cherry picking" is git bissect command. You
could have the some functionality on monotone if people could also
"unpluck" a changeset.

To me is not that important that a full DAG relationship (a graph edge
betwen revisions) is actually stored. The automatic comment added when
pluck is used can be enough (as long as the user can edit it latter to
add/remove as much more detail he wish). If a special cert could be
added with the operation detail, to be used by GUI programs, not
monotone itself, better.

Off course all this could be made simpler to the user by having more
helper commands, like (names for demonstration purpose, only):
  -  "ls patches", to list the changesets currently stored, a local id
and tell if applied;
  - "push <patch/selector>" to add a changeset to the list (pluck on steroids);
  - "pop <id>" to remove a changeset from the list (and eventually
un-apply or just tell user to first manually un-apply it);
  - "apply <id>" to apply one of the changesets on the list;
  - "un-apply <id>" to un-apply a specific changeset from the workspace.

By allowing "apply" and "un-apply" to indicate a range, one could
easily implement bisect using a shell script.

Well, talk is easy and as I will not implement this myself (at least
not in the near term) I believe I should shut up now ;-)


Best regards,
~Nuno Lucas