Unfortunately the patch file does not go with the jar file - it gets applied to the original source files. This goes back to the days when people would pass around source files for programs, not knowing what operating system or architecture or endianness the final program would be used with. The only way to do this cleanly was by passing source files, and then applying patches to the source files.
I did a quick search on the internet, and found an "
Introduction: Using diff and patch (tutorial)". You may want to take a look at this, as the techniques are still in common usage, even with modern languages such as
Java.
I'm going to try to explain how you can get something working to do what you want. There is a risk, though, that I may oversimplify (in which case you may get insulted), or I may leave steps out (in which case you won't understand). If you feel something is insulting, please accept my apologies: it was not intended. If you feel I've left something out, please, please, ask for clarification.
Unfortunately the patch files in that link I provided are rather old, and Tigris, naturally, continued development on SvnAnt past that date. That means that the patch files do not work out of the box. Amazingly the problems are very small, and if you are familiar with editing failed patches / merges, they won't cause you a problem. But I'm going to assume that you want the simplest solution.
So what we need to start with is a version of SvnAnt from around the same time-frame as the patch files. Going back to the link I provided in my earlier post, I see that there are two posts by Dan Prince, each with a patch (diff) file attached. The latest version has the following in the top:
--- test/svn/build.xml (revision 2129)
+++ test/svn/build.xml (working copy)
So I can see that Dan had made modifications to version 2129 of the source code - you will need the source code for that version of SvnAnt. Tigris host it in SubVersion (who would've thought
), and describe how to get it anonymously on the
SvnAnt page under "Latest development". To get the particular version, we need to specify the version on the command line:
svn co -r2129 http://subclipse.tigris.org/svn/subclipse/trunk/svnant/ svnant
Or, if you are using svnant to check out svnout, then I guess it would be:
(I've not used this)
Once you've checked out the code, change to the directory where you checked it out, and run ant - ensure it compiles.
Next you need to download the diff file from the post I pointed you to earlier. Clicking on the "list.diff" link on the email seems to bring it up in a window, then clicking on the "list.diff" link in that window gives you the option to save the file. (I find that interface a little strange, maybe I missed something). Save it to the base directory for the svnant source.
Now you can patch your source code:
patch -p0 < list.diff
patching file test/svn/build.xml
patching file doc/svn.html
patching file src/main/org/tigris/subversion/svnant/List.java
patching file src/main/org/tigris/subversion/svnant/SvnTask.java
(If you are running on any operating system that was built for connectivity, then you will have patch and diff already on your computer. If you are a Microsoft Windows environment, you will need to install them manually. Personally I would go with
CygWin since it gives you a very good Unix environment totally within Microsoft Windows, however if you want a simpler / smaller installation, then
UnxUtils may be better for you.)
Run ant once again, and
you should be all done: you will now have your own version of SvnAnt that includes the list command:
Note: You will be using an old version of SvnAnt, which means the online documentation will not match your version of SvnAnt. You will almost certainly want to get your own version of the documentation: run
ant docs
I tested this on my box with:
And my output file looks like:
Interestingly I also got to see a lot of information about revision information scroll past on the command line:
One final note. Again, if you are familiar with handling merge conflicts, you could try running
svn up to get the code up to the latest version. I have not tried this, but I think you will be safe with accepting the following options:
build.xml - (tc) theirs-conflict - accept their version for all conflicts (same)svn.html - (mc) mine-conflict - accept my version for all conflicts (same)