At 03:10 PM 7/23/2002 -0500, Karl Fogel wrote:
I think someone *did* submit an Ant task at one point; I'm not sure what came of that. I'll ping the list again, but first will wait for answer to the above question, so I don't make nonsense on the list
Hi Karl.
No, not an Ant task. I submitted an Ant build script for Subversion, one which automates the procedure documented in Subversion's INSTALL file of getting Subversion built. It got lost in a sea of patches to Subversion, though, and was never committed. I am reworking it now that both Ant 1.5 and Subversion Alpha have been released. Karl, you can expect it to be resubmitted to Subversion in the next week or two.
As for Ant as a kind of make, it is really something that has a higher level view of the world than make does. I actually used Subversion's make system to do the heavy lifting in the Ant script. Consider the things Subversion's INSTALL file tells you to do: download (or checkout) apr, apr-util, neon, and optionally bdb and httpd2. Install in these locations. Run autogen, configure, make, make test, make install for each package with these options. My Ant build script did all of these things with a single command. The only thing it couldn't do is bootstrap Subversion because, the last time I checked, there was no single URL I could get the tarball from. Sure, you could write a makefile that did all these same things, but no one ever does. make is just a lower level tool.
The reason I haven't written an Ant task for Subversion yet is due to my inability to decide the right way to do it:
a) Use the svn client directly. That would be simplest but requires svn to have been installed previously. Making that assumption about cvs is reasonable, about svn less so.
b) Use the SWIG bindings to Java. This is the way it is supposed to be done (at least according to Greg Stein), but quite apart from the recent volatility (and volatility still to come) in the client-side libraries APIs, there are deployment issues in releasing an Ant task that depends on a JNI-based JAR file. I think that each user would still have to have svn built locally so that the JNI bindings were available. This seems problematic to me in making it part of the core Ant tasks.
c) Use the Jakarta-Slide code as a WebDAV/DeltaV equivalent to Neon and create an all Java Subversion client, mimicking the C codes' layers. That isn't going to happen any time soon, I don't think, and would introduce synchronization issues so that working copies could be used by any client. Even hidden things like the working copy logs should be identical in the Java version so that commands like "svn cleanup" would work after, for example, an Ant task died during a working copy transaction.
I will probably implement a solution based on "a" for a quick fix (unless someone else creates a Subversion task), but I'm still trying to figure out how "b" could be done easily. Long term I much prefer c. Has anybody else here done any work on a Subversion Ant task?
As to the topic at hand, I think that talk of moving Ant to a Subversion repository is premature when we don't even support a task for it yet. Let's wait until we have a task and 1.0 is released (not long now, right Karl?) and clients have started filtering out into the IDEs of the world.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
