On 1/26/08, Thomas Hofer <th_at_monochrom.at> wrote:
> 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).
>
Thanks for explaining this. I hadn't though of antcall being my
problem. I'm not gaining much by using antcall so I could cut that
out.
My other problem was that we need to set the SVN_ASP_DOT_NET_HACK
environment var so that the checked out directories can be used by
Visual studio. While the javahl route respects this variable, the
command line route doesn't, I am guessing that the adapter launches
svn in a empty environment..
Maybe I should start a new thread to ask about that.
regards
Kevin
---------------------------------------------------------------------
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-28 00:22:21 CET