Race condition?

[GoogleCodeExporter]

There looks like a race condition here:

1. svnrevisionlabeller gets the revision number from the <url> 
2. Somebody else commits
3. <sourcecontrol> block executes, and gets different rev. number.

Perhaps the revision number could be got from the svnversion command in the
checkout dir instead?

Original issue reported on code.google.com by carl.cer...@gtempaccount.com on 18 Jun 2009 at 3:14

[GoogleCodeExporter]

You know, that's how I started out with this plugin, and then at some point I 
changed
it to read from the server. If only I could remember what the reason for the 
change was.

Original comment by davidkeaveny on 18 Jun 2009 at 8:24

• Changed state: Accepted
• Added labels: Component-Logic

[GoogleCodeExporter]

Possible work-around:
When is the labeller run? If it is run before the <sourcecontrol> block, then 
the svn
check can use the revision number from the labeller to ensure it checks/updates 
to
the same version as the labeller.

I have to do something like this anyway, because I have a dozen or so <svn> 
blocks
(from a single repo) that are all required for a single project; they all need 
to get
the same revision.

Original comment by carl.cer...@gtempaccount.com on 18 Jun 2009 at 8:39

[GoogleCodeExporter]

OK, so the problem is that the labeller is now slightly out of sync with the 
repository. I switched the code to use SVN INFO against the local copy rather 
than SVN 
LOG against the repository. CC.NET detects a code commit, does its thing, but 
the label 
is out by one. I suspect the labeller runs before the SVN UPDATE updates the 
working 
copy, but I'll have to post a question to the CC.NET group.

Original comment by davidkeaveny on 22 Jun 2009 at 12:31

[GoogleCodeExporter]

Thinking about it, in this situation, won't CC.NET run another build again 
anyway, 
using the same build number for the labeller? Once a build has been initiated 
(your 
step 1), any further commits (your step 2) will queue another build, so the 
situation 
will rectify itself.

I'm strongly tempted to downgrade this one to a WontFix, unless someone wants 
to submit 
a patch?

Original comment by davidkeaveny on 22 Jun 2009 at 1:03

[GoogleCodeExporter]

You can still get the case where the labeller thinks the revision is earlier 
than it
really is. The problem is that step 2 (a new commit) could happen before the 
source
control block checks for new commits. If this happens, it does 'svn update' and 
gets
the latest revision (with the new commit), not the revision that the labeller 
saw.

You're right that a further commit will queue another build if, for example, 
the svn
update is already in progress when a new commit comes in.

Original comment by carl.cer...@gtempaccount.com on 22 Jun 2009 at 1:16