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) anyway.
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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
