No subject

for VendorBranchA removing the file from their code base and the developers
responsible for VendorBranchB still having the file around.

==========================
Question:
==========================
The second update command is aborted "[update aborted]".  The file(s)
responsible for the failure is easily parsed from the command's standard
output and standard error.  The desired behavior in this circumstance is to
then reattempt the update ignoring the problematic file.  I could implement
more complex decision logic, but prefer to simply log the errant file and
move forward (at least for now).

In an attempt to ignore the troublesome file the following attempt to use
the -I option is made:

X:\junk2>cvs update -I mainpackage/coolstuff/test4.txt -j VendorB_1 -j
VendorB_2
cvs update: Updating mainpackage
cvs update: Updating mainpackage/coolstuff
R mainpackage/coolstuff/test4.txt
cvs [update aborted]: cannot open test4.txt for copying: No such file or
directory

As can be seen this is not effective at preventing the "[update abort]".  I
tried several variations on this theme to no avail.  Either the cvs client
being driven is buggy, or I do not understand how to properly use it.  My
intention is to simply detect the problem on the first pass and then skip
over it on the second.

Can anyone provide guidance as to how to get cvs to move forward without
aborting?

============================
Inquiring Minds Want to Know:
============================
In case your wondering there is a corresponding ant import task I have
written which follows the conventions expected by my ant merge task.

James Lee Carpenter
Software Engineer
Household Technical Services
6602 Convoy Court
San Diego, CA 92111

ph: 858-609-2461
email: jlcarpenter at household.com