-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Platform: All, OS: All
-
Powered by SuggestiMate
although i made a new commit, the update was not available during the build. it
gave this:
[server] $ svn update -q --non-interactive --username guest --password guest
$ svn info --xml server
Revision:9493
no change for server since the previous build
environment:
windows 2003,
tomcat 5.5.17,
hudson:1.49
svn client: 1.3.0
[JENKINS-113] in svn update mode, hudson do not detect updates
well, i try again, after i commit from console,
Sending lib\readme.txt
Transmitting file data .
Committed revision 9539.
thisi is the console output from hudson:
[server] $ svn update -q --non-interactive --username guest --password guest
$ svn info --xml server
Revision:9507
no change for server since the previous build
What are the relationship between the 'server' directory that Hudson is building
and the 'lib/readme.txt' that you committed?
It looks like lib/readme.txt isn't in the server directory.
Can you send me or post the job configuration (you can get it from
$HUDSON_HOME/jobs/JOBNAME/config.xml)?
that file was in a directory which belongs the "server" project.
server/deploy/../lib to be exact. i will attach the config to the issue shortly,
also i will checkout the code to see if i can do stg about it.
This is the config.
<?xml version="1.0" encoding="UTF-8" ?>
<project>
<scm class="hudson.scm.SubversionSCM">
<modules>http:...erased by ahmetaa.../server</modules>
<useUpdate>true</useUpdate>
<username>guest</username>
<otherOptions>--password guest</otherOptions>
</scm>
<triggers class="vector" />
<builders class="vector">
<hudson.tasks.Ant>
<targets>war-buildmachine</targets>
<antName>(Default)</antName>
</hudson.tasks.Ant>
</builders>
<publishers class="vector" />
<canRoam>true</canRoam>
<disabled>false</disabled>
<description />
<actions class="vector" />
</project>
I tried to reproduce the problem locally by creating a dummy svn module and a
job set up.
What puzzles me is that in svn the directory revision number is always bigger
(or equal to) the revision numbers of files in it.
So say when you have a module like this in svn:
server
+- dir1
+- lib
+- readme.txt
and if you commit a new readme.txt rev.9539, then it should also create rev.9539
for all its ancestor directories. So when Hudson runs "svn update ...", it
should update the revision of the server directory to 9539. Yet after running
svn update, svn reported that your server directory is still at 9507.
What happens if you run this same "svn update -q --non-interactive --username
guest --password guest" command at the Hudson workspace directory manually? Is
there something strange about workspace that prevents this update? Maybe -q is
suppressing interesting messages?
yes, i was puzzled too because even now when i run
svn info --xml server
from the hudson workspace, it gives me this result:
----------------------------------------
<?xml version="1.0" encoding="utf-8"?>
<info>
<entry
kind="dir"
path="server"
revision="9507">
<url>http://--erased--/trunk/server</url>
<repository>
<root>http://--erased--/projects</root>
<uuid>75bc6971-29f9-0310-ad29-836d730da295</uuid>
</repository>
<wc-info>
<schedule>normal</schedule>
</wc-info>
<commit
revision="9507">
<author>-erased-</author>
<date>2006-09-08T19:26:46.234603Z</date>
</commit>
</entry>
</info>
---------------------------
i suspect that i know something fundamentally wrong about svn then.
seems like when you run the "svn info --xml server" command it is only bringing
the latest revision of the "current" working directory, not the latest revision
of the project. because if i do it like this:
svn info --xml http://--erased--/trunk/server
<?xml version="1.0" encoding="utf-8"?>
<info>
<entry
kind="dir"
path="server"
revision="9546">
<url>http://--erased--/trunk/server</url>
<repository>
<root>http://--erased--/projects</root>
<uuid>75bc6971-29f9-0310-ad29-836d730da295</uuid>
</repository>
<commit
revision="9546">
<author>-erased-</author>
<date>2006-09-09T01:48:31.618907Z</date>
</commit>
</entry>
</info>
so basically the info command should be run using the repository url, not
working directory.
But right before Hudson runs "svn info --xml server", it runs "svn update" in
the server directory (which is what "[server]" prefix means), so it surely
brought the latest rev.9546 to the local workspace?
Can you run the same "svn update" command that Hudson runs, but without -q
option? I suspect for some reasons "svn update" is not bringing over the latest
revision.
if i go to the Hudson_home/...server/workspace/ and run the "svn update (witohut
-q)" from console it brings the updates correctly. However, even hudson make the
update call before calling the "svn info" when i trigger the build, i dont see
the updates in the workspace that i comitted. maybe i am doing something very
wrong from the beginning.. is your test working as expected in update mode?
If you have checked out a workspace, perhaps you might try removing that "-q"
from Hudson's SubversionSCM.java. Maybe it's showing some warning or something.
(But Hudson checks the svn exit code, so I'd imagine if there's something wrong,
it will tell you so.)
And yes, when I run this test on my system (with the server on localhost), it
works too. Another possibility you might check is if there's any clock
difference between the svn server and the Hudson machine (not the time zone
difference, the clock skew.) If Hudson couldn't update the workspace but you
were able to do so manually later, then clock sounds like a possibility.
sorry koshuke, but we are in crunch time, i cannot test any further the issue
for some days. However, i did change the svn server's time (make it 1 minute
further then the build server) but still same behavior. for now we will go with
not using update, after all it works that way. this seems like an issue with our
usage or environment, so feel free to resolve the issue as cannot reproduce or
something. it would be nice if some other person tests this too.
Thanks. I'm sorry that we couldn't fix the problem.
I'll keep it open for a while to see if someone else will have the same problem.
If not, I'll close it as not reproducible.
Starting 1.74, Hudson uses Java subversion implementation, and hopefully we
won't see strange problems like this.
The log said the revision after you made a new commit is 9493. When you
committed, svn should report you the new revision. What was it? Was it 9493,
9494, etc?