[Proposal] Extend optional PVCS tasks

[Andrew May <am...@ingenta.com>]

Hi,

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 (Pcli.java?), 
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,

Andrew

Re: [Proposal] Extend optional PVCS tasks

[Glenn McAllister <gl...@somanetworks.com>]

Andrew May wrote:

> 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.

See http://jakarta.apache.org/site/source.html for starters; you will be
most interested in the "Patches" section.  As for the coding conventions,
Turbine has explicitly defined their standards at
http://jakarta.apache.org/turbine/code-standards.html , while in general we
haven't.  The rule of thumb is, follow the standard in the existing file
because it is *really* irritating to see style changes in the same file.
The only hard and fast rules are:

1. No tabs, only spaces.
2. 4 spaces per "tab".

You know, looking at Turbine's conventions, I have to admit I like them.  Do
the committer's have any strong feelings about adopting a consistent
standard?  Or more accurately, stating what our defacto standard is?

> 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 (Pcli.java?),
> 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).

As do I, so I'd encourage you down that path.

> 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).

Submit patches, and hopefully someone will have time to check them out.

Glenn McAllister
SOMA Networks, Inc.