ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew May <>
Subject [Proposal] Extend optional PVCS tasks
Date Mon, 02 Jul 2001 15:52:28 GMT

Having used the optional Pvcs task to perform a large GET from our PVCS 
repository on Unix, and found it a lot faster than using the Windows GUI 
(unsurprisingly), I'm interested in extending the tasks to include 
versioning (currently very slow for us using the GUI, and a bit error 
prone), and possibly using promotion groups.

Not having developed for Ant before, and not being that familiar with 
the coding conventions used I could use some advice in how to proceed.

In all these cases we're dealing with the bulk of our repository (the 
parts that are part of the application, not requirement docs etc.), and 
so the mechanism used currently for the GET where a list of files is 
generated using the PVCS pcli command and then processed using 
"<command> @tmpfile" is appropriate. We're not really interested in 
using it to checkout/in individual files because we've got the GUI. 
However, I appreciate that others may want to add tasks for these things.

I had a few thoughts on how to structure this:

1) Extend the existing Pvcs task to have a "command" argument, which 
could be "Get", "Version", "Promote" etc. This would make it a bit like 
the CVS task, but has the problem that some arguments would not make 
sense for a particular command. It also might get a bit messy!

2) Create PvcsGet, PvcsVersion, PvcsPromote tasks and deprecate Pvcs 
task. Split out the common functionality which is mostly in getting the 
list of files from the repository using the plci command (, 
and then just have the appropriate arguments for each task (although a 
lot of these would be common).

3) Keep the Pvcs task with the common arguments and have nested elements 
for the different commands. This would probably be more difficult to 
write :), and in reality it would be a bit like 2) with the Pvcs task 
doing the list of files and the command elements (with a PvcsCommand 
interface or something) doing the get/version/promote. I'm concerned 
that the structure of the tags would be reflecting the underlying PVCS 
commands, and also that this might not support tasks for individual 
files very well.

Personally I favour 2).

I would also like to incorporate any fixes/improvements suggested to 
what's already there, and add more arguments to support more of the 
command line options (like quiet output).

Thanks in advance,


View raw message