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

Peter Nicolai wrote:
> > 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 am guessing that both calls to svn info are working properly, but
> that svn update is only partially succeeding - it is obviously getting
> to the point where it has contacted the server, because it always
> reports the correct latest version in the repository, even though it
> is printing it the wrong way, and twice.
>
> > I added a debug switch to cause Hudson to dump the "svn info --xml"
> > output that it's getting.
>
> Ok, console output is attached.

Thanks. Looks like "svn info --xml" launched from Hudson does indeed 
report 12156. But when you run the same command from CLI in the Hudson 
workspace, you'll get 12159, right?


> > 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".
>
> see above - but basically I am wondering if the first svn info is
> causing the svn update to fail, not the other way around, and the
> second svn info is correctly reporting that the working directory
> never changed because svn update wasn't allowed to.

Can you think of any way to test your hypothesis? Like maybe a delay 
between each svn invocation so that you can reasonably be confident that 
processes are invoked in a sequence?

--
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi@xxxxxxx

smime.p7s
Description: S/MIME Cryptographic Signature