|
| From: | graydon hoare |
| Subject: | [Monotone-devel] Re: Cherry-Picking, Renames, Etc. |
| Date: | Mon, 29 Nov 2004 12:40:27 -0500 |
| User-agent: | Mozilla Thunderbird 0.8 (X11/20040913) |
Oren Ben-Kiki wrote:
A --> B --> C \ D --> E \ working copy then 'monotone update $C' will perform a merge of your working copy and C, using E as the common ancestor, writing the result into your working copy.I thought "update" will use "A" as the common ancestor, merging "C" into the current working copy - completey ignoring "B", "D" and "E"...
there is some confusion here. the "normal" update algorithm (just plain "monotone update") wouldn't do anytning in this circumstance because there are no descendants of E.
njs is making reference to the fact that there is a "new" update algorithm which takes arguments ("monotone update $foo"), which does something fancier like either what you're describing or a cherry pick or something. I haven't investigated it yet (I didn't write it) but there's lots you can do there. there's enough machinery to support many similar sorts of commands with not much effort.
I must be missing something here. Maybe "update" doesn't do what I think it does... but re-reading the doc I'm get the impression it uses "A" as the common ancestor. In contrast, what I propose is using *B* "as if" it was the ancestor of the working copy version - which on the face of it is rather crazy.
no, that's very much what we have in mind, using the predecessor revision as a "fake" common ancestor in order to support cherry picking. we've all come up with the same plan.
Now, if you did a "patch", you'd have a second kind of entry: from-revision: <start-of-patch> to-revision: <result-of-patch>
hm. on the face of it I am not very interested in adding this concept to a revision.
The main reason you do this is for documenting the "geneology" of therevision. If I applied the "fix memory leak" patch from the unstable branch into the stable one, I want it to be on record, and not as some human-provided text buried in a comment somewhere - it should be visible in the graph. So the sort of "clever things" you can do is run queries, like "show me revisions that incroporated the memory leak patch", or answering questions like "was the memory leak patch incroporated into this revision?".
well, understand that recording "who patched whom" doesn't prove much: the merging might have been done poorly, the transplanted "fix" broken on transplant. the bug may survive. if you want to do QA you should really make a test for the bug, not make a list of "good patches" and go looking for them.
anyways 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.)
Yes. IMVHO, this is one thing Arch got right. Except that AFAIK they don't do the "I guess you did a move" using diff sizes and cached external uid files. Then again, I haven't looked at it in great detail for a while.
ok. I disagree. I think the cost (in mess and complexity) outweighs the benefit. to be clear, this only helps when:
- you rename files (rare enough in the first place)
- and you threw out most history so you can't construct identities
- and you want to copy patches around
- and you aren't willing to tolerate the occasional "please clarify
which file you want to apply this to" from monotone
but I accept the reasoning arch uses, and don't need to discuss it
further. monotone is free software and mostly amenable to "evidence
based requirements": if you want to make a little branch, make this
feature, try it out, and report back how much of a tangible difference
it makes to you, go for it. if it really makes a big difference in daily
use (not theoretical arguments) I'll be more willing to make changes myself.
Finally, you don't have to add a uid line in your source file, there's always "plan B" (keeping a .monotone-uid/<file>.uid file near the source) which is pretty invisible, is generated automatically for you (when you do an "add") and also works. So different tastes are accomodated (to some extent).
in "plan B", monotone needs to be told of every rename operation as well, so it can adjust the contents of the .uid file.
here's "plan C" (which is the current plan): keep enough rename history around that you can figure out which file came from which other, and in the worst case ask for help. you don't seem to think this is viable. why not?
If I move it it in a GUI, I have to get to the CLI and type a "monotone rename" command, including at least one (and probably two) longish path name I can't cut&paste from the GUI. Ugh.
in this case, monotone will complain that it can't find the file when you try to commit.
in any case, VC tools do get upset when you damage their concept of the working copy without telling them. one option is to complain -- let the user fix it -- and one option is to try to automatically adapt to the damage. currently we complain, and nobody's yet reported this behavior as surprising, just speculated that it *could* be made quasi-automatic with guids-in-comments, excepting a bunch of other cases like backup files and binaries.
This is the law of "conservation of pain". You can shift it between file creation, rename, or merge/update/commit time - either way, its there.
oh, I've never seen such a law. sometimes you can make things less painful by adjusting implementation, and I'm willing to do so if it looks clearly like the change *will* lower user pain. I'm just not convinced the structure you're suggesting helps. plan A involves embedding data in files, scanning every findable file for these strings, checking for uniqueness, and intelligently masking out backups and duplicates. plan B involves a situation where you still have to tell monotone about all the rename/add/del actions. neither seems like a big "reduction in pain" from what we have now.
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. if it becomes clear through use that this is actually hurting us, I may change my mind, but right now I've never hit it as anything beyond a theoretical problem.
-graydon
| [Prev in Thread] | Current Thread | [Next in Thread] |