[Fwd: Re: (Hudson) Issue #167 - SVN Update not working]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[Fwd: Re: (Hudson) Issue #167 - SVN Update not working]

Kohsuke Kawaguchi-2

I forgot to forward this to [hidden email].

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

Peter Nicolai wrote:

> I set up j2ee and hudson on a fresh machine, with just the svn
> commandline client (I wondered if TortoiseSVN could have been
> interfering or something but it doesn't look like it).  Anyway I get
> the same behavior... I'm using Sun's app server that comes with j2ee
> now, but I tried tomcat and got the same result.  Anyway, I made a
> small SVN dir just for testing this that just has one batch file,
> "test.bat", that echos a message and returns 0.  I changed "This is
> rev 1" to "This is rev 2" and committed.  here's the console output
> from hudson:
>
> started
> $ svn info --xml test_hudson
> [workspace] $ svn info --xml test_hudson
> [test_hudson] $ svn update --non-interactive  --username  pnico
> At revision 12156.
> At revision 12156.
> $ svn info --xml test_hudson
> [workspace] $ svn info --xml test_hudson
> Revision:12154
> no change for test_hudson since the previous build
> [workspace] $ C:\Documents and
> Settings\pnico\.hudson\jobs\test\workspace\hudson31292.bat
>
> C:\Documents and Settings\pnico\.hudson\jobs\test\workspace>test_hudson\test.bat
>
> C:\Documents and Settings\pnico\.hudson\jobs\test\workspace>echo "This
> is rev 1"
> "This is rev 1"
>
> C:\Documents and Settings\pnico\.hudson\jobs\test\workspace>exit 0
> finished: SUCCESS
>
> Here is the output of svn info --xml from the command line:
>
> C:\Documents and Settings\pnico\.hudson\jobs\test\workspace>svn info
> --xml test_hudson
> <?xml version="1.0"?>
> <info>
> <entry
>    kind="dir"
>    path="test_hudson"
>    revision="12155">
> <url>https://scrapyard/svn/PROJECTS/test_hudson</url>
> <repository>
> <root>https://scrapyard/svn/PROJECTS</root>
> <uuid>4b969ea7-6005-0545-b4f1-58d74d991439</uuid>
> </repository>
> <wc-info>
> <schedule>normal</schedule>
> </wc-info>
> <commit
>    revision="12154">
> <author>pnico</author>
> <date>2007-01-03T23:07:12.091802Z</date>
> </commit>
> </entry>
> </info>
Thanks. This is actually interesting. SVN update reported that it
updated the workspace to 12156, but there's no "12156" in this output at
all. Hudson looks for /info/entry/commit/@revision, so that's why it
found the workspace to be in 12154.

Maybe "svn info test_hudson" is not the right way to find out the
current workspace revision? Where did 12156 go?


> I still think something is messing up svn update... there is no normal
> way to call svn update once and get that output without the working
> directory having been been previously updated.  If the working
> directory is not up to date, "At revision 12156" is not even part of
> the output.  It will say this instead:
>
> C:\Documents and
> Settings\pnico\.hudson\jobs\test\workspace\test_hudson>svn update
> --non-interactive --username pnico
> U    test.bat
> Updated to revision 12156.
>
>
> Finally, here is svn info --xml again, after updating properly:
>
>
> C:\Documents and Settings\pnico\.hudson\jobs\test\workspace>svn info
> --xml test_hudson
> <?xml version="1.0"?>
> <info>
> <entry
>    kind="dir"
>    path="test_hudson"
>    revision="12156">
> <url>https://scrapyard/svn/PROJECTS/test_hudson</url>
> <repository>
> <root>https://scrapyard/svn/PROJECTS</root>
> <uuid>4b969ea7-6005-0545-b4f1-58d74d991439</uuid>
> </repository>
> <wc-info>
> <schedule>normal</schedule>
> </wc-info>
> <commit
>    revision="12156">
> <author>pnico</author>
> <date>2007-01-03T23:27:11.458584Z</date>
> </commit>
> </entry>
> </info>
I added a debug switch to cause Hudson to dump the "svn info --xml"
output that it's getting. Could you grab the snapshot build of #1868 or
later, run "hudson.scm.SubversionSCM.dumpSvnInfo=true" from the
scripting console, and run another build? I'd like to see what it produces.


>> When you schedule a next build, I believe "svn update" will still report
>> "At revision 12144." while the next "svn info" reports "Revision:12138".
>>
>> So this eliminates the hypothesis that the execution order or timing is
>> an issue.
>
> I was wondering if somehow both commands were trying to execute
> *simultaneously*, and if that might be causing svn update to
> malfunction - both in failing to overwrite the files and in printing
> the goofy output.  The fact that the second svn info command then
> reports that the update never occured doesn't surprise me.
The code in question executes programs sequentially. And even if they
run concurrently, if "svn update" didn't update any file (which is the
case when it reported "At revision XXXX"), I don't think it could cause
a bad interference with "svn info".

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
smime.p7s (4K) Download Attachment