[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: Cherry-Picking, Renames, Etc.
From: |
Oren Ben-Kiki |
Subject: |
[Monotone-devel] Re: Cherry-Picking, Renames, Etc. |
Date: |
Mon, 29 Nov 2004 20:47:18 +0200 |
User-agent: |
KMail/1.7.1 |
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
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., (continued)
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/29
- [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Bruce Stephens, 2004/11/29
- [Monotone-devel] Invariant failure on propagate., Jean Pierre LeJacq, 2004/11/29
- Re: [Monotone-devel] Invariant failure on propagate., Nathaniel Smith, 2004/11/29
- Re: [Monotone-devel] Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/30
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Nathaniel Smith, 2004/11/29
Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/30
Re: [Monotone-devel] Cherry-Picking, Renames, Etc., Nathaniel Smith, 2004/11/28
- Re: [Monotone-devel] Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/29
- [Monotone-devel] Re: Cherry-Picking, Renames, Etc., graydon hoare, 2004/11/29
- [Monotone-devel] Re: Cherry-Picking, Renames, Etc.,
Oren Ben-Kiki <=
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/29
- [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Bruce Stephens, 2004/11/29
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Joel Rosdahl, 2004/11/29
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Oren Ben-Kiki, 2004/11/29
- [Monotone-devel] Re: Cherry-Picking, Renames, Etc., graydon hoare, 2004/11/29
- Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc., Nathaniel Smith, 2004/11/29
Re: [Monotone-devel] Cherry-Picking, Renames, Etc., Nathaniel Smith, 2004/11/29
[Monotone-devel] Re: Cherry-Picking, Renames, Etc., graydon hoare, 2004/11/28