ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn McAllister <>
Subject Re: [Proposal] Extend optional PVCS tasks
Date Tue, 03 Jul 2001 13:41:11 GMT
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 for starters; you will be
most interested in the "Patches" section.  As for the coding conventions,
Turbine has explicitly defined their standards at , 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 (,
> 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.

View raw message