ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Subversion in Ant (was Re: Attribute naming)
Date Fri, 02 Aug 2002 17:33:44 GMT
At 09:09 AM 8/2/2002 +0200, Stefan Bodewig wrote:

>Talking of a task for subversion, it may be better to bundle it with
>subversion than to include it with Ant's distribution.  It would
>require a svn command line client (if I understand you correctly)

I'm sure it could be hosted with Subversion, but I don't recommend it. I 
understand the motivation of keeping the task in sync with the client but I 
don't think this is much of an issue because the interface of the command 
line client is fairly stable. Even in places where there is talk of 
changing it, the changes are minor (how much output to show when the quiet 
flag is passed) or backwards compatible (file:// changes).

Compare that to the cost for Subversion users of leaving it out of Ant 
proper. Retrieving code from SCM systems is core to performing builds, 
which is why we support such a variety of them. If a Subversion task is not 
part of Ant, everyone who wants to use it has to find the task class in 
their Subversion installation and include a <taskdef> with the appropriate 
classpath. We couldn't easily share build files with Subversion tasks 
because the classpath would have to be stored in a separate property that 
changed for each user. Not a huge hurdle, but a barrier to adoption of 
Subversion that seems unnecessary.

Almost all of the SCMs we support that I can see (CVS, Perforce, VSS, SOS, 
PVCS, Continuus, Clearcase) require a separate client. Starteam is the one 
exception, but it requires its own dependency to be installed, a JAR file. 
So I don't see the requirement of a client (or client library if I can 
solve the deployment and reliability issues) as an argument against. Nor is 
a client necessarily going to be required in the long term, since I could 
see developing an all Java client for Subversion once the working copy 
format stabilizes and Subversion becomes completely DAV/DeltaV compliant, 
probably within a year.

As far as the maintenance burden goes, I've been a contributor to the 
Subversion project for a year now, so I'm willing to take on all the 
maintenance duties there, as well as to provide the task in the first place.

And if others are willing to do the same with arch and Stellation, these 
arguments apply to tasks developed for them as well.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message