I do not have the permission to see BSP-839. How and when will the solution be made available?

Regards,

Wim

The issue that Ringo has reported is being handled as BSP-839.

Mark,

I doubt if this issue is really fixed. I have a test setup with Bamboo 2.0.2 on a Windows 2000 machine, with CVS polling based build plans. Every rlog command doesn't return any results:

{{22-mei-2008 09:09:11 Running CVS log command: "rlog -N -r -d2008-05-21 12:52:53 +0200< main "
22-mei-2008 09:09:11 ... in: "C:/Data/bamboo/xml-data/build-dir/MAIN-HEAD/main"
22-mei-2008 09:09:11 ... CVSROOT: ":pserver:username@ourcvshost:/dvlp/loc/cvs/repositories/tina"
22-mei-2008 09:09:12 Found 0 change sets in the change logs}}

If you look back in the history of this issue, Sam made a comment about the quotes and the trailing space in the cvs rlog command. I adapted the command with the info he made and got the following results now:

{{$ cvs rlog -N -r -d"2008-05-20 12:00:00<" main
cvs rlog: Logging main

RCS file: /ourcvshost/dvlp/loc/cvs/repositories/tina/main/.cvsignore,v
head: 1.2
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 3; selected revisions: 0
description:
=============================================================================}}

<cut much more log information>

Can you look into this again?

Ringo

Just want to confirm that 2.0b9 fixes the problem nicely.

(You might want to keep in mind the issue w/ lingering lockfiles, incase the shift to log/rlog causes any other cvs users to run into problems. It was caused on our side by malformed ,v files in the Attic that led any log or rlog command that hit those files to fail.)

Sam,

Thanks for the help on this!

Beta 9 should be out tomorrow, please give it a try and see how you go

Cheers,

Mark C

I had a hunch that it could be returning quickly because there was no data to check on, so looked on the box in the build dir, this is what I see:

-bash-3.00$ pwd; for A in `ls .`; do echo Looking in: $A; ls $A; done;
/n/bin/bamboo/data_20b6/xml-data/build-dir
Looking in: LW-COMPILE
Looking in: LW-COMPILE15
Looking in: LW-COMPONENTS
Looking in: LW-MAGNET
limewire
Looking in: LW-MAVEN
Looking in: LW-NIGHTLY
limewire
Looking in: LWS-DEF
build-number.txt clover.license deploy documentation lib LICENSE.txt pom.xml scripts src target velocity.log

It seems that after the import, no CVS dirs were created in plans that have a change-triggered CVS repository. LWS-DEF is svn-based, and LW-MAGNET & LW-NIGHTLY are scheduled. Interestingly, the first build of LW-NIGHTLY showed no changes, but the second did. (LW-MAGNET likely did the same thing, but I'm not sure.) LW-COMPILE, LW-COMPILE15, LW-COMPONENTS, and LW-MAVEN never found anything to build.

The scheduled build found changes because it did a log on existing files the second night, whereas every other build (and scheduled on the first night) find no changes.

Perhaps rlog should be used instead of log? log apparently requires that the files exist already, in order to check their log. I think this wouldn't work for new files or directories (or new files within new directories), as well as not working if nothing's checked out in the first place.

I wonder if it's the SSH link that's causing the issue. We'll try to test it out and see how that goes.

I'm running the pserver build locally and it seems to be picking up the changes (and building), albeit slowly.

Sam,

I'm trying to look into this further by replicating the LimeWire environment. Are you using the CVSROOT

:pserver:guest@cvs.limewire.org:/cvs

The strangeness you see (rogue spaces, no escaping) is only an artifact of the toString method in the CVS library we're using.

One interesting thing in your logs is that the cvs log command returns very quickly.

2008-03-23 09:38:33,410 INFO [pool-17-thread-1] [CvsRepositoryManager] Running CVS log command: "log -N -S -r -d2008-03-20 13:31:00 -0400< "
2008-03-23 09:38:33,410 INFO [pool-17-thread-1] [CvsRepositoryManager]                  ... in:  "/n/bin/bamboo/data_20b6/xml-data/build-dir/LW-COMPILE15/limewire"
...
2008-03-23 09:38:33,719 INFO [pool-17-thread-1] [CVSRepository] Found 0 change sets in the change logs

That's a 300 millsecond return... In my test, the log commands take a significantly longer time to complete so I think there's something wrong here. I'm adding some optional extra logging that we can use.

Cheers,

Mark C

I attached the logs to BSP-633

Hi Mark –

I downloaded beta6 and re-exported from 1.2.4 & imported into beta6. Lots of news to report. Firstly, it imported without a hitch – the various XML bugs are totally fixed, and Bamboo got up and running without any problems.

As for the CVS problems... I did a bit of sleuthing and discovered some interesting things. I ran 'cvs log' with all the same parameters that Bamboo used, from the same directory, and on Cygwin I got a 'Terminated fatal signal 11'. I tried running it on our cvs box (Linux) and got a Segmentation fault. So that led me to thinking the problem was in CVS itself. Every time it failed, it was on the 'core/com/limegroup/gnutella' directory. So I tried running a CVS log for every file in there, but it worked fine. Then I tried running it for every file in the Attic. It failed on one particular one – there was a file called 'UrnFactory.java,v' and another 'URNFactory.java,v' – probably some sort of confusion from using a CVS client on Windows (case insensitive) and having the server on Linux (case sensitive). URNFactory.java,v had good info, but UrnFactory.java,v was tiny, and was causing the segmentation fault. So I renamed it (to UrnFactory.java,v.BROKEN), and voila – the seg faults disappeared. (In that directory, atleast... I had to do the same thing in another Attic.)

So, cvs log & cvs rlog work now. However... Bamboo still isn't picking up changes. I note from the activity logs that Bamboo is running the command:

.... Running CVS log command: "log -N -S -r -d2008-03-20 13:31:00 -0400< "

Note the extra space after the '<'. If I run that command locally, I get:

-bash-3.00$ cvs -q -d/cvs log -N -S -r -d2008-03-20 13:31:00 -0400\<
cvs log: nothing known about 13:31:00
cvs log: nothing known about -0400<

If I put quotes around the date & include the space, as in:

-bash-3.00$ cvs -q -d/cvs log -N -S -r -d"2008-03-20 13:31:00 -0400< "

Then I get no results. But... If I remove the space, as in:

-bash-3.00$ cvs -q -d/cvs log -N -S -r -d"2008-03-20 13:31:00 -0400<"

Then I get results!

I have no clue what Bamboo is actually running internally, but I suspect it might now be failing because of that errant space.

(Sorry I can't attach bamboo's logs right now... our sysadmin isn't around, and I'm at home and can't ssh into the build server. [But can into the cvs server.. heh.])

Hope that helps!

Sam,

I've updated the code for CVS repository for beta6 (which just went out). If you have time to try it sometime that'd be much appreciated.

If it's still a problem, please attach the atlassian-bamboo.og file agan to the issue as well as the output from running

cvs log FileName.txt

That we we should be able to better diagnose what timing related issues may be causing changes to not be picked up.

Cheers,

Mark C

Hi Mark – All the info is attached to BSP-633. Thanks!

Sam,

I'm looking into this further... Can you please attach your full atlassian-bamboo.log to this issue? That might give us more clues.

Also:

• Are CVS & Bamboo server on the same timezone?
• Are you running distributed builds? Or just the one build?

Cheers,

Mark C