<!-- 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> John Fetkovich <fetko@slaysys.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. To compile a DTD in to a perl module: vcp revml X-dtd *this*file* X-save-doctype where "X" is a "-" (silly XML comments). This will write ./lib/RevML/Doctype/vV_VV_.pm where V_VV is the underscorified version #FIXED attribute from the revml ENTITY definition below. --> <!ELEMENT revml ( time, rep_type, rep_desc, comment?, rev_root, branches?, rev* ) > <!-- NOTE!! When changing the dtd, this version number should be changed also. Any change also requires re-compiling the dtd with bin/compile_dtd. For more info run 'vcp help Maintenance' and read the section titled 'Updating the RevML DTD.' --> <!ATTLIST revml version CDATA #FIXED "0.32" > <!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 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. This comes before branches because it's needed to modify branches, specifically the p4_branch_spec's View field. That's a theoretical issue as implemented, but it's nice to have things in the safest, most mnemonic order, I think. --> <!ELEMENT branches (branch*) > <!-- A list of <branch> elements --> <!ELEMENT branch (branch_id, dest_branch_id, (p4_branch_spec)* ) > <!-- <branch> elements declare names for a branch in different repositories. Right now, a <branch> element must have a branch_id and a dest_branch_id, and it's up to the user to fill in the dest branch id appropriately for the destination repository (a branch tag for CVS, a repository path for Perforce or (one day) subversion). Later, we can add an attribute and allow multiple dest_branch_id tags if people want to target multiple repos from the same source. Pretty unlikely... 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. --> <!ELEMENT branch_id (#PCDATA) > <!-- cvs: <branch_id>r_1_3_b</branch_id> p4: <branch_id>//depot/foo/devel</branch_id> The contents of this element is used to identify the branch being branch being exported. --> <!ELEMENT dest_branch_id (#PCDATA) > <!-- cvs: <branch_id>r_1_3_b</branch_id> p4: <branch_id>//depot/foo/devel</branch_id> The contents of this element is used to identify the branch being branch being exported. --> <!ELEMENT p4_branch_spec (#PCDATA|char)* > <!-- If the source repo was p4, then all branch specs with branch ids used in the export are included, one per <branch> tag. This may be parsed by the destination (see the subroutines VCP::Utils::p4->{parse,build}_p4_form()) or submitted directly to the destination p4 repository. --> <!ELEMENT rev ( name, source_name, source_filebranch_id, source_repo_id, ( ( type, (branch_id,source_branch_id)?, rev_id, source_rev_id, (change_id,source_change_id)?, digest ) |( type, (cvs_info|p4_info|source_safe_info|pvcs_info)?, (branch_id,source_branch_id)?, rev_id, source_rev_id, (change_id,source_change_id)?, time, mod_time?, user_id, (p4_action|sourcesafe_action)?, label*, lock?, comment?, (move|(previous_id?,(content|delta),digest)) ) |( type?, (cvs_info|p4_info|source_safe_info|pvcs_info)?, (branch_id,source_branch_id)?, rev_id?, source_rev_id?, (change_id,source_change_id)?, time?, mod_time?, user_id?, (p4_action|sourcesafe_action)?, label*, lock?, comment?, previous_id?, delete ) ) ) > <!ATTLIST rev id CDATA #REQUIRED > <!-- each <rev> must have a unique identifier, usually the name and revision number, though the precise format depends on the source repository. The id should be derived from the metadata in a repeatable fashion. --> <!-- 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. <previous_id> contains the id string of the revision before this one. --> <!-- The reason the <delete> variant is broken out is that VSS does not associate much info with deletions or track them per revision. So, a delete can have some info in it for other SCMs, but will be mostly empty for VSS. --> <!-- 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 used when importing data in to the same type of repository it was exported from. --> <!ELEMENT p4_info (#PCDATA|char)* > <!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 previous_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). --> <!-- The following source_* fields are intended to keep the corresponding fields without 'source_' in VCP all the way through to the destination unchanged for making labels and logging. --> <!ELEMENT source_name (#PCDATA|char)* > <!ELEMENT source_rev_id (#PCDATA) > <!ELEMENT source_change_id (#PCDATA) > <!ELEMENT source_branch_id (#PCDATA) > <!-- These fields are similar in purpose to above, but don't have directly corresponding analogues without the 'source_' prefix. --> <!ELEMENT source_filebranch_id (#PCDATA) > <!ELEMENT source_repo_id (#PCDATA) >
# | 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. |