[Monotone-devel] Re: Cherry-Picking, Renames, Etc.

[Oren Ben-Kiki]

On Monday 29 November 2004 19:40, graydon hoare wrote:
> njs is making reference to the fact that there is a "new" update
> algorithm which takes arguments ("monotone update $foo")...

And:

On Monday 29 November 2004 19:48, Nathaniel Smith wrote:
> Hmm, the doc won't help you, since this behavior is brand new and
> possibly undocumented (?).  The doc is describing the behavior of
> update when you don't give an argument,

Ah. I see. Question: does the new update allow me to specify the target, 
as well as the base revision? That is, given:

  A --> B --> C --> D
    \-> E -> working set

Can I "monotone update $B $C"? Update has its own ideas about the target 
revision, which seem inappropriate here.

(I'm trying to build monotone to see for myself on my Gentoo machine, 
for some reason it refuses to believe I have the boost library 
installed, which I do. I'm delving into the internals of the configure 
script right now...).

graydon hoare wrote:
> ... if you do want to record this information I think it fits
> better as a cert rather than part of the revision object: so-and-so
> *claims* X is a transplant of Y. it's not something I see any of
> monotone's algorithms using anyway, so I doubt it'll hurt if
> accopmanied by all the usual weakness of certs (disagreeing certs,
> variable trust, etc.)

And:

Nathaniel Smith wrote:
> Traditionally this is the sort of reason that people keep
> ChangeLog files... hmm.  We have some precedence for saving this sort
> of information in automatically generated changelog certs; both
> "merge" and "propagate" record what happened this way.

Seems like a sensible approach, as long as the information is stored.

This made me put my finger on why I'm uneasy with considering this an 
"update" variant, though. It boils down to a philosophical question: do 
you provide the minimal set of primitive operations and let people use 
them in certrain ways to achieve their intent, or do you provide 
higher-level commands that directly express specific user intent?

The primitive operation here is "merge revision A into the working set 
using revision B as a common ancestor". This covers merge, update, 
propagate (I think), and patch. So, in theory, you could get away with 
having a single "monotone 3-way-merge" command.

Monotone does have separate merge and update commands - to pick one 
example - and for a good reason; the caller's intent is very different. 
One is "update me to the latest revision on my branch" while the other 
is "merge the latest revision of the other branch into this one".

The difference in intent _does_ causes differences in the behavior of 
the commands; Specifically, an update changes the "old revision", while 
a merge adds another one. And, "merge" adds certs in a certain way, 
while update doesn't.

It seems to me that this approach requires having a "patch" command 
separately from the "update" command. the intent of a "patch" is 
different from both a "merge" and an "update", the generated certs will 
be different...

You could(should?) also provide a low-level "intent-free" command 
("monotone 3-way-merge") to allow people to just play around. Maybe 
they'll discover new "intent-based" commands... But IMVHO it should be 
distinct from any "intent-based" command.

About uids:

> > In YAML, our policy is that when something boils down to a taste
> > issue, we defer to the project's founder
>
> ok. that's me, and for the time being (not set in stone, but for now)
> I'd prefer not to tangle with any additional form of uid.

Like I said, I hereby solemnly promise never to raise the issue again. I 
do like Bruce's point about splitting commit into two phases - deciding 
what to do, and then doing it - as a way to open up the door for doing 
"clever things", without affecting monotone itself.

Have fun,

 Oren Ben-Kiki