Kevin Glynn wrote:
> I have starnge behaviour, which seems consistent accross various
> machines and platforms that I have tried it on. I have an ant file
> that does a succession of checkouts. For the first one it uses javahl,
> but for all the following ones it decides to use the command line
> interface. Here is the relevant portion of the ant build file:
>
> <target name="-svn-checkout">
> <echo>Checkout srcUrl="${svn.src}" destPath="${work.dir}"</echo>
> <svn>
> <checkout url="${svn.src}" destPath="${work.dir}"/>
> </svn>
> </target>
>
> <target name="getScormEngineNet" depends="init">
> <antcall target="-svn-checkout">
> <param name="svn.src" value="${svn.scormenginenet.url}/CentralInterface"
> /> <param name="work.dir"
>
value="${client.build.dir}/RusticiSoftware.ScormContentPlayer.CentralInterface"/>
> </antcall>
> <antcall target="-svn-checkout">
> <param name="svn.src" value="${svn.scormenginenet.url}/DataHelp"/>
> <param name="work.dir"
> value="${client.build.dir}/RusticiSoftware.ScormContentPlayer.DataHelp"/>
> </antcall>
> <antcall target="-svn-checkout">
> <param name="svn.src" value="${svn.scormenginenet.url}/Logic"/>
> <param name="work.dir"
> value="${client.build.dir}/RusticiSoftware.ScormContentPlayer.Logic"/>
> </target>
I had the same problem, too. The bug is triggered by the antcall. If you
avoid antcalls, your problem will go away.
I had been assigned to support some annoyed developers who had to migrate
their CVS based ant scripts to SVN. I do not remember the details of our
marathon debugging session, but in essence the problem is that there is an
object that thinks it is a singleton... the trouble is, it gets loaded more
than one time, because each antcall is executed using a new classloader.
The first time it works correctly (i.e. javahl works), but the second time
(the second antcall) this "singleton" throws an exception during
initialization and the SvnClientAdapter falls back to the svnkit or
commandline backend.
Since our scripts depend strongly on antcalls, we decided to disable javahl
and svnkit completely and are using only the commandline adapter now. The
behavior on our windows system was especially strange, because javahl
stores the credentials on disk using a windows encryption library. When
svnant fell back to svnkit during the second antcall, it could not decrypt
those credentials, because it is a pure java implementation and therefore
can't use the windows encryption libraries - it stores the passwords as
cleartext, which is not acceptable for us. The result was that the user
authentication worked for the first update command, but not for the second
one (which has been executed in a second antcall).
regards,
Thomas Hofer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
Received on 2008-01-26 17:57:43 CET