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/07/2002 09:21:40 AM |
| List: | com.perforce.revml |
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!]
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, since it is by definition identical to the version from which it was branched in the parent branch; the metadata records this. (This is what we refer to az "lazy copying"). Technically it's in the db.rev record. (but also noted in a pair of db.integ record, one for each direction [parent->child, child->parent]).
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. (Some might argue that this loses information, but I'd argue that it's a good design tradeoff: it's history I've never minded losing.) To undertsand this, it helps to remember that you can do branching in perforce most of the time quite nicely without having to use branch view spaces at all, since you can effectively supply simple one-line branch veiws on the "p4 integrate" command line. (In my mind branch views are a crutch that can currently help to compensate for the fact that "p4 integrate" doesn't yet do the calculation of the transitive closure if branching relationships yet. I.e., it allows you to record the fact that main/foo.c was branched to branch/foo.c and then renamed branch/bar.c in the child branch, by having a "complex" (> 1-line) branch mapping. You can also do other strange and wonderful things with complex & baroque branch maps - but I guess I digress; I think we can happily solve the simple case for the conversion needs at-hand!)
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.
5. Handle merges as best as possible. Merges don't really affect cvs, but when doing p4->p4, it would be nice to simulate merges; not sure how to do this easily. I'd like to do the equivalent of a "p4 resolve" that would let me alter the file on disk instead of through the interactive resolve, then have "p4 submit" get the file like the p4 edit does. Something like the "am" action in the interactive mode, for example. Is there a p4 incantation for that (I've never had to do it and haven't been able to concoct such an incantation here)? As a fall-back, we could use P4MERGE and supply "m\n" to an interactive "p4 resolve" session.
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.
7. A branch map is a mapping of source repository branches to destination repository branches. A branch map will contain the branch records. Branch maps should be extractable, probably using a command like:
vcp cvs:/module branchmap:foo.bmap
The resulting files would be XML and perhaps also as YAML (http://yaml.org/). The motivation for optionally supporting YAML is that it is a less cluttered file format that administrators may find easier to read and alter. It may not be enough easier to warrant the extra effort involved, however, especially in the first implementation. The XML format is required because branch maps must be able to exist "naturally" in RevML and so that additional tools (generic XML tools, textual interfaces and GUIs) can be brought to bear on branch maps without implementing a new format with an uncertain future (YAML).
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.
8. Branch mapping files should be editable by hand and then (optionally) usable when doing a transfer:
vcp cvs:/module/... --branchmap=foo.bmap p4://depot
Sounds good.
10. Branch maps should not be required when doing a transfer if it is possible to make intelligent guesses about branch names. An inability to make intelligent guesses should cause an error message and exit without altering the destination repository.
Good.
11. Both "external wrapper" and integrated text and GUI clients should be supported by the branch map concepts and implementation.
Sure.
Examples of branch metadata are: - branch name/tag/label - location in repository - whether or not to transfer the branch - product-specific data - like Perforce's branch view.
(Which may not exist, though you can certainly construct one for any "simple" 1-1 branch mapping).
- cvs's branch (and "magic branch") number - vcp/RevML's assigned branch id. - Perhaps a branch comment
Examples of per-file branch metadata are: - base version (what Perforce calls "source" or "theirs") - location in repository - version id (<rev_id> in RevML terms)
This metadata is all distinct from the actual file metadata, which for the first version in the branch would contain such data as - user performing the branch - when the branch was performed - the comment entered while branching. - the branch id (if necessary; with cvs the <rev_id> contains a branch number and with Perforce the file's location should be enough to identify the branch in most cases if not all; we need to identify any counter examples to this assumption).
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).
So, Barrie... I will not pretend to have plunged into the XML for <branch> and <rev> that comes at this point in your spec; as I mentioned, I'm involved in a tactical ploy to make a stopgap [till you get this great stuff in place!] *fast* CVS-Perforce converter, and I need to turn my attention to thsat for now.
From the prose in the proposal you've written to this point, it seems like you're on-target.
Hope this was helpful. Let me know if any of what I wrote sparks questions.
You may also find, when thinking about the Perforce side of things, that the Perforce database schema information at
http://www.perforce.com/perforce/doc.011/schema/index.html
is useful.
- Richard Geiger Open Source Engineer at Perforce