<!-- DTD for RevML (see <revml> version attdef for version) Authors: Barrie Slaymaker <barries@slaysys.com> . Greg Kroah-Hartman <greg@kroah.com> Sean McCune <sean@sean-mccune.com> --> <!-- The order is specified for the tags so that they are in an appropriate order for an import utility. Some of these constraints may be relaxed in the future, but in general the metadata will always precede the object data. Import utilities *must* cache all necessary metadata regardless of order of occurence, then may discard it once the <content> is seen. --> <!ELEMENT revml ( time, rep_type, rep_desc, comment?, file_count?, ((branch_map_id,branch_map_sn)|branch*)?, rev_root, rev* ) > <!ATTLIST revml version CDATA #FIXED "0.28" > <!ELEMENT rep_type (#PCDATA) > <!-- 'p4', 'cvs', 'sourcesafe', etc. --> <!ELEMENT rep_desc (#PCDATA|char)* > <!-- The version number, platform, etc. for the repository. This may be needed so that import utilities can figure out what tags mean what when a particular repository version changes. This is often the output of 'p4 info' or 'cvs -v' + cvs environment settings and the cvs -l command. --> <!ELEMENT file_count (#PCDATA) > <!-- How many files to be processed. This is because we can't possibly load a large revml file in to memory, yet it's nice for an import utility to be able to display a % done progress bar. There is no semantic constraint on this number: it must only be used for progress indication, and may be any nonnegative integer value. It may also be wrong, and import utilities must still function correctly but give a warning. --> <!ELEMENT branch_map_id (#PCDATA) > <!-- Required in all revml files that do not contain <branch> elements but do contain <branch_id> elements. Also required in branch map files. --> <!ELEMENT branch_map_sn (#PCDATA) > <!-- Indicates the serial number of the branch map. This is required in all revml files that contain the <branch_map> tag. It is used to detect the use of different branch mappings between the import and export utilities. --> <!ELEMENT branch (branch_id, cvs_branch_id?, p4_branch_id?, sourcesafe_branch_id?) > <!-- <branch> elements declare names for a branch in different repositories. This is provisional. The mapping of branches between foreign repositories is not designed yet. A set of <branch> elements defines a mapping of branches from one repository to another. It may be incorporated in the same revml file as the revision data, or it may be defined externally, in which case it must be visible to both the import and the export utilities. In particular, there is a cohesive concept of a branch across multiple files in some products but not in others. Whether or not and if so, how, we deal with this is going to wait until we get to some real implementations and encounter the devil in the details. Among other things, we probably need a branchml DTD for branch mappings that are separate. We may also need facilities for split branch mappings: cvs_branch -> branch_id in one file, and branch_id -> p4_branch in another file. The that DTD must be included in the revml DTD so that branch mappings can be shipped along in a single file. --> <!ELEMENT branch_id (#PCDATA) > <!-- cvs: <branch_id>r_1_3_b</branch_id> p4: <branch_id>devel</branch_id> The contents of this element is used to identify the branch being referred to by the export utility. When in a <branch> element it's contents will usually be duplicated in a vendor-specific branch tag. --> <!ELEMENT cvs_branch_id (#PCDATA) > <!-- Typically a rev tag --> <!ELEMENT p4_branch_id (#PCDATA) > <!ELEMENT sourcesafe_branch_id (#PCDATA) > <!ELEMENT rev_root (#PCDATA|char)* > <!-- The root of the tree that was extracted to RevML. This is usually the source file spec up to (but not including) the first component that does not contain a wildcard. --> <!ELEMENT rev ( name, type, ( (rev_id,change_id?,digest) |( (cvs_info|p4_info|source_safe_info|pvcs_info)?, branch_id?, rev_id, change_id?, time, mod_time?, user_id, (p4_action|sourcesafe_action)?, label*, lock?, comment?, (delete|move|((content|(base_name?,base_rev_id,delta)),digest)) ) ) ) > <!-- A few words about the digest, content, and delta elements: We could have allowed <content> or <delta> without the digest, but it's safer this way and the digest is small. <delta> tags should only be used for second and later <rev>s for a given <name>. A digest alone is only used for base revisions that should already be in the target repository, for incremental updates. If there's no <delete/>, <move/> or <content>..</content> elements, it's a base rev digest. The first <rev> for a given name must not contain a <delta>. It should contain <content> if this is not an incremental update, or just a <digest> if it is. The rev//digest with no <content> can only be used as the first <rev> in the file for a given <name>. it indicates that the <rev_id> revision of <name> should be recovered from the target repository and then checked against the <digest> field. The <base_name> is optional and is assumed to be the same as <name> if not present. <base_rev_id> could be made optional someday, too. These are provided so that branching may be indicated and so that the RevML reader does not need to perform revision number math, respectively. Yes, <base_name> and <base_rev_id> could have been attributes of <delta>. They're not since they contain metadata, and I've been trying to limit the use of attributes to describing encodings, etc. --> <!-- We will add repository_... tags as needed to carry along all necessary repository specific information without alteration. --> <!ELEMENT name (#PCDATA|char)* > <!-- the file name, in Unix format, relative to the repository root. The file/directory names '.', '..', and '' are not legal. cvs: 'src/iface/ftree/fi.c p4: 'depot/perl/perl.c', not '//depot/perl/perl.c' We will add vendor_... tags if this format causes loss of information. --> <!ELEMENT type (#PCDATA) > <!-- 'text' or 'binary' --> <!-- Product specific tags. These are only used when importing data in to the same type of repository it was exported from. --> <!ELEMENT p4_info (#PCDATA|char)* > <!-- No need for rev_id here, it's in the main section --> <!ELEMENT cvs_info (#PCDATA|char)* > <!ELEMENT source_safe_info (#PCDATA|char)* > <!ELEMENT pvcs_info (#PCDATA|trunk_rev_id|attrib|char)* > <!-- Repository-nuetral tags. These must be generated by all export utilities, and must be used by all import utilities when importing from a foreign repository type. --> <!ELEMENT rev_id (#PCDATA) > <!-- A small integer indicating the revision number of a file *within the branch*. cvs: "3" if the cvs rev is "1.3" p4: the file revision number sourcesafe: the file version number --> <!ELEMENT change_id (#PCDATA) > <!-- Export utilities are responsible for grouping revisions together using a unique change_id. change_id's are integers starting at 1 for each file. --> <!ELEMENT trunk_rev_id (#PCDATA) > <!ELEMENT attrib (#PCDATA) > <!ELEMENT lock (time?, user_id) > <!ELEMENT time (#PCDATA) > <!-- All times are in ISO-8601 format in GMT/UCT0 <time>2000-12-31 23:59:59Z</time> --> <!ELEMENT mod_time (#PCDATA) > <!-- Modification time --> <!-- All times are in ISO-8601 format, GMT --> <!ELEMENT p4_action (#PCDATA) > <!ELEMENT sourcesafe_action (#PCDATA) > <!ELEMENT label (#PCDATA|char)* > <!ELEMENT user_id (#PCDATA|char)* > <!ELEMENT comment (#PCDATA|char)* > <!ELEMENT delete EMPTY > <!ELEMENT move (name) > <!-- Where the file moved to --> <!ELEMENT delta (#PCDATA|char)* > <!ATTLIST delta type (diff-u) #REQUIRED encoding (none|base64) #REQUIRED > <!ELEMENT base_name (#PCDATA|char)* > <!ELEMENT base_rev_id (#PCDATA) > <!ELEMENT content (#PCDATA|char)* > <!ATTLIST content encoding (none|base64) #REQUIRED > <!ELEMENT digest (#PCDATA) > <!ATTLIST digest type (MD5) #REQUIRED encoding (base64) #REQUIRED > <!ELEMENT char EMPTY > <!ATTLIST char code CDATA #REQUIRED > <!-- char elts are used to pass on control codes that would otherwise cause the XML to be non-well-formed. Each instance must have an attribute code containing a hexadecimal representation of the character code as string like "0x0c" (that for a ^L or form feed). -->
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#19 | 4514 | Barrie Slaymaker | - VCP::Rev::earlier_ids and <release_id> added | ||
#18 | 4507 | Barrie Slaymaker |
- RevML: - added <action>, removed <delete>, <placeholder> and <move> - added <from_id> for clones (and eventually merge actions) - Simplified DTD (can't branch DTD based on which action any more) - VCP::Source::cvs, VCP::Filter::changesets and VCP::Dest::p4 support from_id in <action>clone</action> records - VCP::Dest::perl_data added - VCP::Rev::action() "branch" added, no more undefined action strings - "placeholder" action removed |
||
#17 | 3993 | Barrie Slaymaker | - Fold in changes from clkao's SVN work | ||
#16 | 3970 | Barrie Slaymaker |
- VCP::Source handles rev queing, uses disk to reduce RAM - Lots of other fixes |
||
#15 | 3943 | Barrie Slaymaker | - RevML supports comments in placeholders | ||
#14 | 3801 | Barrie Slaymaker |
- remove <branches> from DTD - revml.dtd is now at v0.34 |
||
#13 | 2972 | Barrie Slaymaker | Interim checkin | ||
#12 | 2802 | John Fetkovich |
Added a source_repo_id to each revision, and repo_id to each Source and Dest. The repo_ids include repository type (cvs,p4,revml,vss,...) and the repo_server fields. Changed the $self->...->set() and $self->...->get() lines in VCP::Dest::* to pass in a conglomerated key value, by passing in the key as an ARRAY ref. Also various restructuring in VCP::DB.pm, VCP::DB_file.pm and VCP::DB_file::sdbm.pm related to this change. |
||
#11 | 2743 | John Fetkovich |
Add fields to vcp: source_name, source_filebranch_id, source_branch_id, source_rev_id, source_change_id 1. Alter revml.dtd to include the fields 2. Alter bin/gentrevml to emit legal RevML 3. Extend VCP::Rev to have the fields 4. Extend VCP::{Source,Dest}::revml to read/write the fields (VCP::Dest::revml should die() if VCP tries to emit illegal RevML) 5. Extend VCP::{Source,Dest}::{cvs,p4} to read the fields 7. Get all tests through t/91*.t to pass except those that rely on ch_4 labels |
||
#10 | 2059 | Barrie Slaymaker | Support for branching in p4->p4 added | ||
#9 | 2051 | Barrie Slaymaker | Enable p4_branch_spec to be carried through revml->revml. | ||
#8 | 2017 | Barrie Slaymaker |
Interim checkin of id=/base_version_id for revml: and branch_diagram: |
||
#7 | 2015 | Barrie Slaymaker | submit changes | ||
#6 | 1998 | Barrie Slaymaker | Initial, revml and core VCP support for branches | ||
#5 | 1795 | Barrie Slaymaker | further DTD tweakery | ||
#4 | 1794 | Barrie Slaymaker |
Dumb down DTD to handle VSS, which does not store revision info for deleted files. |
||
#3 | 478 | Barrie Slaymaker |
0.05 Mon Dec 18 07:27:53 EST 2000 - Use `p4 labels //...@label` command as per Rober Cowham's suggestion, with the '-s' flag recommended by Christopher Siewald and Amaury.FORGEOTDARC@atsm.fr. Though it's actually something like vcp: running /usr/bin/p4 -u safari -c safari -p localhost:5666 -s files //.../NtLkly //...@compiler_a3 //.../NtLkly //...@compiler_may3 and so //on //for 50 parameters to get the speed up. I use the //.../NtLkly "file" as //a separator between the lists of files in various //revisions. Hope nobody has any files named that :-). What I should do is choose a random label that doesn't occur in the labels list, I guess. - VCP::Source::revml and VCP::Dest::revml are now binary, control code, and "hibit ASCII" (I know, that's an oxymoron) clean. The <comment>, <delta>, and <content> elements now escape anything other than tab, line feed, space, or printable chars (32 <= c <= ASCII 126) using a tag like '<char code="0x09">'. The test suite tests all this. Filenames should also be escaped this way, but I didn't get to that. - The decision whether to do deltas or encode the content in base64 is now based on how many characters would need to be escaped. - We now depend on the users' diff program to have a "-a" option to force it to diff even if the files look binary to it. I need to use Diff.pm and adapt it for use on binary data. - VCP::Dest::cvs now makes sure that no two consecutive revisions of the same file have the same mod_time. VCP::Source::p4 got so fast at pulling revisions from the repositories the test suite sets up that CVS was not noticing that files had changed. - VCP::Plugin now allows you to set a list of acceptable result codes, since we now use p4 in ways that make it return non-zero result codes. - VCP::Revs now croaks if you try to add two entries of the same VCP::Rev (ie matching filename and rev_id). - The <type> tag is now limited to "text" or "binary", and is meant to pass that level of info between foreign repositories. - The <p4_info> on each file now carries the one line p4 description of the file so that p4->p4 transferes can pick out the more detailed info. VCP::Source::p4, VCP::Dest::p4 do this. - VCP::{Source,Dest}::{p4,cvs} now set binaryness on added files properly, I think. For p4->p4, the native p4 type is preserved. For CVS sources, seeing the keyword substitution flag 'o' or 'b' implies binaryness, for p4, seeing a filetype like qr/u?x?binary/ or qr/x?tempobj/ or "resource" implies binaryness (to non-p4 destinations). NOTE: Seeing a 'o' or 'b' in a CVS source only ends up setting the 'b' option on the destination. That should be ok for most uses, but we can make it smarter for cvs->cvs transfers if need be. |
||
#2 | 468 | Barrie Slaymaker |
- VCP::Dest::p4 now does change number aggregation based on the comment field changing or whenever a new revision of a file with unsubmitted changes shows up on the input stream. Since revisions of files are normally sorted in time order, this should work in a number of cases. I'm sure we'll need to generalize it, perhaps with a time thresholding function. - t/90cvs.t now tests cvs->p4 replication. - VCP::Dest::p4 now doesn't try to `p4 submit` when no changes are pending. - VCP::Rev now prevents the same label from being applied twice to a revision. This was occuring because the "r_1"-style label that gets added to a target revision by VCP::Dest::p4 could duplicate a label "r_1" that happened to already be on a revision. - Added t/00rev.t, the beginnings of a test suite for VCP::Rev. - Tweaked bin/gentrevml to comment revisions with their change number instead of using a unique comment for every revision for non-p4 t/test-*-in-0.revml files. This was necessary to test cvs->p4 functionality. |
||
#1 | 467 | Barrie Slaymaker | Version 0.01, initial checkin in perforce public depot. |