CHANGES for vcp - Version CoPy

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.

0.04 Tue Dec 12 00:15:57 EST 2000
   - Reorg of VCP::Source::p4
     - One large filelog command is run instead of many small ones.
       This takes advantage of the -m option to make sure enough changes
       are listed.  Many extra revisions of most files are probably
       listed, but listing and ignoring them is quicker than spawning p4
       over and over.  Wish p4 filelog had a revision range...
     - it now doesn't suck the entire filelog output in to memory, it
       parses it line by line as it's emitted from the `p4 filelog`
     - `p4 print` is now used to print a bunch of files at once, using
       the header line to separate one file from the next, kind of like
       splitting a mime-encoded message.  There's a very slight chance
       that it will misjudge the boundary between two files if a file
       happens to have a line that looks very much like the header line
       for the next file.  This is pretty unlikely and I'll fix it if it
       crops up.  I could batch them more, right now it never puts two
       revisions of the same filename in the same batch, for no really
       good reason.  Another method might be to batch 25 or 50 revs each
       time.
     - it turns out there's a problem spawning multiple p4 commands at
       the same time against the same p4d (p4d is 99.2, FWIW).  Or at
       least running large `p4 files ...` while there's a large `p4
       filelog` still also running.
     - filelog lines beginning with "... ..." are now ignored.  These
       are notifications of copy, branch, and integrate events that we
       don't yet do anything with.
     - deleted cur() and P4_CUR
     - deleted P4_IS_INCREMENTAL
   - Made an assertion in VCP::Dest::revml::handle_rev() a little
     clearer
   - Added some ok(1) calls to 90p4.t to make it easier to figure out
     which child process is whining or aborting
   - Made the message that's printed when a subcommand emits unexpected
     output say "stderr" instead of "stdout".
   - Cleaned up documentation for VC::Plugin::work_path().

0.03 Sun Dec 10 13:14:07 EST 2000
   - Cleaned up VCP::Source::p4 a bit.  It doesn't whine as much now
     when it sees what it considers to be old news in the log file.
   - Added an easy way to monitor the commands being issued to a
     repository: simply add "::cmd" to the debug spec for that source:

	vcp -d Source::cvs::cvs
        vcp -d Dest::p4::p4

   - The next step is to use the -m option to p4 filelog to speed things
     up.

0.02 Tue Dec  5 01:20:31 EST 2000
   - 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.

0.01 Sat Dec  2 23:10:43 EST 2000
   - First public release.  Moderately functional alpha code.  Supports
     p4, cvs, RevML.  Expect APIs, UIs and enerthing else to change before
     things settle down.

