ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walker Joe <>
Subject RE: Source code task
Date Thu, 28 Sep 2000 12:55:10 GMT

I agree that moving between source code control systems is non-trivial - the
motivation however is more do to with simplicity for the user. VSS or P4
users can not benefit from using any CVS examples that came with ant's

The real debate here is - how similar are CVS and VSSGET. While I agree that
the ant tasks _as defined_ are not identical - they could be a lot closer
than they are. The fundamental concepts are get/edit/put on version X of
file Y.

There is no reason why CVS (and P4) can not have recursive="true" and no
reason why VSSGET can not have quiet="true". The differences are due to the
implementations of the tasks not due to the nature of the underlying

I agree that there may be some concepts that are difficult - the cvs cvsroot
seems to cover the vss ssdir/vsspath/login ideas, there may be more. However
I don't think that this makes things impossible - harder to program yes. It
makes things easier for the user - and that is more important than easier to
program, IMHO.


> -----Original Message-----
> From:	Stefan Bodewig []
> Sent:	Thursday, September 28, 2000 1:06 PM
> To:
> Subject:	Re: Source code task
> >>>>> "WJ" == Walker Joe <> writes:
>  WJ> The javac task is nice, IMHO, because I can swap between 1.2,
>  WJ> 1.3, and jikes with the flip of a switch
> I think the situation is different for source control systems. How
> often are you going to change the system - and given the work you have
> to put into transferring the sources from say CVS to Clearcase,
> changing a single line in your build file won't hurt that much.
> What works out nicely for javac/jikes is that they share a lot of
> attributes people typically want to set, I'm not sure if this holds
> true for source control systems. Lets take a look at the task we have
> right now:
> <!ATTLIST cvs
>           date CDATA #IMPLIED
>           quiet %boolean; #IMPLIED
>           command CDATA #IMPLIED
>           noexec %boolean; #IMPLIED
>           cvsroot CDATA #IMPLIED
>           dest CDATA #IMPLIED
>           package CDATA #IMPLIED
>           tag CDATA #IMPLIED>
> <!ATTLIST vssget
>           recursive %boolean; #IMPLIED
>           ssdir CDATA #IMPLIED
>           date CDATA #IMPLIED
>           vsspath CDATA #IMPLIED
>           version CDATA #IMPLIED
>           writable %boolean; #IMPLIED
>           login CDATA #IMPLIED
>           label CDATA #IMPLIED
>           localpath CDATA #IMPLIED>
> dest => localpath, tag => label or version, cvsroot => vsspath+login
> but that's all. The rest is either only useful for cvs or for vssget,
> at least this is what the authors thought.
> You'd either end up with an additional-attributes entry or a bunch of
> magic properties (like build.compiler.emacs) for the things not
> covered by the common denominator.
> I'd say, keep them as separate task - and give the user a chance to
> only include the task she actually needs once we have the extension
> system in place (Ant 2.0).
>  WJ> In the short term I'm going to start on a P4 task.
> It could be included as an optional task if you want.
> Stefan

Legal Disclaimer:-

Please be aware that messages sent over
the Internet may not be secure and should
not be seen as forming a legally binding
contract unless otherwise stated.

View raw message