5 messages in com.perforce.revml[revml] Re: Adding Branching to vcp a...| From | Sent On | Attachments |
|---|---|---|
| rm...@perforce.com | 07 Feb 2002 09:21 | |
| Barrie Slaymaker | 07 Feb 2002 12:29 | |
| rm...@perforce.com | 08 Feb 2002 11:55 | |
| Barrie Slaymaker | 08 Feb 2002 12:52 | |
| rm...@perforce.com | 08 Feb 2002 14:57 |
| Subject: | [revml] Re: Adding Branching to vcp and RevML |
|---|---|
| From: | rm...@perforce.com (rm...@perforce.com) |
| Date: | 02/08/2002 11:55:19 AM |
| List: | com.perforce.revml |
[About terminology]
It's all a mazy of twisty little sematics; at times all alike; at others all different
Yep, but we can trust that the bird will have got the snake, when all's said and done. (Sorry to anyone in the audience to young to have enjoyed the wonders of ASCII-based first-person adventures)
I also get it confused; let me read some docs from this system or that and I get them backwards too. If it were standard in the industry, I'd just fo with the flow... the version/revision distinction I make is a blurry one though.
Well, of course we [at Perforce] would like Perforce to become the de-facto, but...
If I were on _that_ standards committee, I'd propose
revision and deltas
I think, but maybe that's my current Perforcentricity showing.
[...]
The key question here (in lieu of a direct-access backend for p4d metadata) is whether or not it "seems" to exist when viewed through the command line: the command line presents a consistent view that rev#1 on the branch exists even though it's the moral equivalent of a hard link to the base version (that version which is being branched). We'll need to keep in in mind if we ever "go direct".
That's all spot-on; but note, IMHO, "going direct" is part of the plan, at least for us at Perforce and our desire to have a RevML/vcp-based suite of conversion tools. I.e., I still think it will be a win (and perhaps a necessity) to get the speed it can give us. (But just maybe support for and a great process involving a well-defined approach for "incremental" conversions will tip the scale away from "going direct"). We'll see.
[...]
The reason for speccing it in is, for p4->p4 transfers, (1) so the view can be transferred whether or no the integrate has occured and (2) so that people who expect it to be there in the destination rep will find it there.
Ah, yes, that makes sense.
[...]
So, anyway, my point here is simply that RevML branch records probably don't want to record Perforce "branch views", but rather the simple branching relationship between a parent branch version and the newly branched child version.
I'm not sure how useful/manageable the insertion is; the devil's in the details. On the one hand, I think it can't hurt to extract it for now whether or not it's used (yet, if ever); on the other I think "who wants to do extra work??". I'll consider it strictly optional for now :).
Sure, but now that you have me thinking about it, genning up some simple branch specs in a * -> Perforce conversion wouldn't be a bad thing at all, and probably exactly what many people would want (or even expect) to happen. Also, it probably should be hard at all to do, once you have all the information you need in order to do the branching as proposed.
Ah, merges. I agree that we can leave this can of dragons unopened for the time being, and in the context of converstion from one SCM to another.
Ok, bumped from the initail version.
I think that's OK, but in this case it might be my "CVS->Perforce"-background that's showing. (I.e., In CVS, to the limits of my understanding, the is no "merge information" (i.e., what we think of as integratin records in Perforce). (Users might be able to invent thier own way of doing this with cleaver stashing of information in tags, but CVS just doesn't go there.
I guess other more "modern" SCMs must. So: yeah, think about it (never good to paint oneself into a corner), but don't consider it part of the spec for now, at least.
Again, the surprising thing here is that Perforce doesn't really _have_ anything like this at a high level; it's all kept file-by-file.
Still, yes, I think it's a valuable concept for vcp/RevML and conversion tools.
Perforce's extreme flexibility in this respect worries me as a conversion tool writer; it delights me (if only in concept, prefer to avoid such complexities) as a user :). I'm mostly concerned about being able to easily specify the Perforce "directory" that, say, a CVS branch should wind up in.
Good. I think we're square on all that.
[...]
Examples of branch metadata are: - like Perforce's branch view.
(Which may not exist, though you can certainly construct one for any "simple" 1-1 branch mapping).
Yep. One could certainly mount an arguement that it would be good SCM practice to avoid some of the more esoteric avenues that Perforce allows. But I think that's part of the brilliance of Perforce's design. (Christopher, if you're listening, I trust that won't go to you head). It starts with a very broad and simple set of capabilities, which happen to be very well suited to modelling what happens in SCM. But it's a two-edged sword, since it allows you to build worlds which are both warm and cozy, or (if you over-reach, or leap before you look), are, uh... less warm and cozy. Anyway, you seem to have the Zen of it.
No need to include it if it doesn't exist in the source rep. Not looking to create things out of rarified air ;).
Again, see my comment above: it may be so worthy, and so so simple to do, that you won't be able to resist. Really good magicians should be allowed to play with rarified air now and again, if they kow what they're up to. Kenneth Lay, on the other hand... (Will the term "We're Layed" gain currency as an expession of dismay, I wonder?)
Hope so; I'm sure I've overlooked something, but we'll find it in the code!
Yep.