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: | Barrie Slaymaker (barr...@slaysys.com) |
| Date: | 02/07/2002 12:29:42 PM |
| List: | com.perforce.revml |
On Thu, Feb 07, 2002 at 09:22:02AM -0800, rm...@Perforce.com wrote:
My comments on the first-cut branching design spec:
Definitions
[I note your vcp terminology, and will try to use it properly below, but bear with me if I slip up!]
It's all a mazy of twisty little sematics; at times all alike; at others all different (and yes, I spent far too many hours playing Dongeon and Zork back when ;). 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.
3. Revisions affected by branching should not need to refer to the branch record.
I think this is OK; but note:
In Perforce, the first version of a file created by "simple" branching (p4 integrate main/file branch/file && p4 submit) doesn't result in an actual copy in new branch in the repository
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".
4. Branch records need to be able to capture generic and product-specific metadata. Generic metadata includes base and target versions. Product specific metadata includes Perforce branch views.
Actually, the way Perforce works, branch views are applied by the "p4 integrate" command at execution time, to construct a list of "donor" and "recipient" versions (for branching, if the "recipient" doesn't currently exist, or for merging, if the "recipient" does). But after that fact, the branch view spec could be deleted without affecting the revision history of the files themselves in any way.
*nod*; I thought this was the case, thanks for confirming.
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.
I think we can happily solve the simple case for the conversion needs at-hand!)
Heh, I think that scenario can't be captured easily from most other products :).
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 :).
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.
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.
Thinking in the context of your comments on Perforce's branch views, I can squint and see this as an inter-repository branch view, though less developed and less flexible than Perforce's.
The per-file branch info is supposed to be able to override the branch map, of course, in the same way you can integrate so you could pull things will-nilly from various places, but I don't think the resulting branch would necessarily line up wrt change numbers properly if you did that. IOW, doing a p4 intergrate with a sophisticated branch view would let you pull together a lot of spaghetti in one change; doing it with the per-file branch info in VCP would result in a separate change number for each bunch of spags somehow, I suspect.
Too subtle for v1.0, though, like you say, though you have me thinking that I *might* be able to use a branch view to good effect here, I'm not sure how and it's a hopefully rare situation in inter-repository transfers.
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).
No need to include it if it doesn't exist in the source rep. Not looking to create things out of rarified air ;).
This distinction between branch, per-file branch, and file metadata is made for several reasons:
(And shows a reassuring level of understanding of the problem, I'd say).
Hope so; I'm sure I've overlooked something, but we'll find it in the code!
So, Barrie... I will not pretend to have plunged into the XML for <branch> and <rev> that comes at this point in your spec
No problems, the RevML is serving only as a convenient display technology (in that it's handy and mimics the internal data structures very closely; it's not the most legible). If I can't represent it accurately in the RevML, it won't fly in the internal data structures.
Hope this was helpful. Let me know if any of what I wrote sparks questions.
Very.
You may also find, when thinking about the Perforce side of things, that the Perforce database schema information at
Wow, thanks. Never seen it before. Worth the price of admission, I'd say ;)
- Barrie