[5504] Checking for changes and problems pulling

I've a very large cvs module, but the build in question only needs one
top-level folder of the whole module (which has around 10 total top
level folders). I've configured TeamCity to only include the one top
level folder** and it currently spends 40 minutes doing the initial
"Checking for changes" step.

: Checking for changes
: Building in c:\TeamCity\buildAgent\...

I actually think it hangs or something, because if I try to cancel
during this 40 minutes, the cancellation also hangs. I haven't the
patience to see how long the cancellation takes. (Seems I need to
restart the Agent service to get things going again).

After it's done checking for changes (I guess TeamCity times out? Dunno
- I've restarted TeamCity with log4j set to DEBUG level, but nothing in
the log files says what happens at this magical 40 minute timeout), the
build will continue on, and it will start to pull files normally, but
then mysteriously stop - it doesn't pull all the files it should, and
then of course the compile fails.

I've setup a separate project with TeamCity on the same CVSNT server,
much smaller (~10-20MB) and it works fine (we're running the latest
version of CVSNT - connecting through its extnt tool that handles the
sspi protocol for us - same way we do for Eclipse), so I know there's
nothing inherently wrong with our connectivity to CVSNT, though I
certainly don't know who's to blame in this current issue.

If there's anything I can do on my end with TeamCity to get better
diagnostic info, please let me know. Anything I can turn on to get a
dump of the raw CVS communications / maybe any error messages the CVS
server is returning - that'd be great.

-- Chris


    • Maybe I'm just dense, but your docs on the Checkout Rules don't

explicitly say you can use a single inclusion rule:

+:src

to only include that one folder. The docs say:

-:PathName | Excludes PathName
+:VCSPath=>. | Maps the VCSPath...

and a third variation on mapping. It'd be nice, IMO, to have the docs
talk about the +: option without any mapping. I came away from the
initial read thinking the only way to get the one top level directory
was to exclude all the others. FWIW...

4 comments

Hello Chris,

what is the server build number? Is it Agra or Benaris EAP?

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Chris Morris" <chris.morris@einstruction.com> wrote in message
news:fc4bo1$u24$1@is.intellij.net...

I've a very large cvs module, but the build in question only needs one
top-level folder of the whole module (which has around 10 total top level
folders). I've configured TeamCity to only include the one top level
folder** and it currently spends 40 minutes doing the initial "Checking
for changes" step.

>

: Checking for changes
: Building in c:\TeamCity\buildAgent\...

>

I actually think it hangs or something, because if I try to cancel during
this 40 minutes, the cancellation also hangs. I haven't the patience to
see how long the cancellation takes. (Seems I need to restart the Agent
service to get things going again).

>

After it's done checking for changes (I guess TeamCity times out? Dunno -
I've restarted TeamCity with log4j set to DEBUG level, but nothing in the
log files says what happens at this magical 40 minute timeout), the build
will continue on, and it will start to pull files normally, but then
mysteriously stop - it doesn't pull all the files it should, and then of
course the compile fails.

>

I've setup a separate project with TeamCity on the same CVSNT server, much
smaller (~10-20MB) and it works fine (we're running the latest version of
CVSNT - connecting through its extnt tool that handles the sspi protocol
for us - same way we do for Eclipse), so I know there's nothing
inherently wrong with our connectivity to CVSNT, though I certainly
don't know who's to blame in this current issue.

>

If there's anything I can do on my end with TeamCity to get better
diagnostic info, please let me know. Anything I can turn on to get a dump
of the raw CVS communications / maybe any error messages the CVS server is
returning - that'd be great.

>

-- Chris

>
>
>

    • Maybe I'm just dense, but your docs on the Checkout Rules don't

explicitly say you can use a single inclusion rule:

>

+:src

>

to only include that one folder. The docs say:

>

-:PathName | Excludes PathName
+:VCSPath=>. | Maps the VCSPath...

>

and a third variation on mapping. It'd be nice, IMO, to have the docs talk
about the +: option without any mapping. I came away from the initial read
thinking the only way to get the one top level directory was to exclude
all the others. FWIW...



0

Olesya Smirnova wrote:

Hello Chris,

what is the server build number? Is it Agra or Benaris EAP?


TeamCity Version 3.0.1 EAP (build 5504)

(is that what you're asking for?)


--
Chris

0

Chris Morris wrote:

it currently spends 40 minutes doing the initial
"Checking for changes" step.

: Checking for changes
: Building in c:\TeamCity\buildAgent\...

I actually think it hangs or something, because if I try to cancel
during this 40 minutes, the cancellation also hangs.



I've further confirmed this by setting up another install of CVSNT with
a restored copy of the repository, and TeamCity against it works fine.
(Though doing a clean check-out seems much slower than using TortoiseCVS
on a workstation)

Can y'all give me more information about what CVS commands are issued
during the "Checking for changes" step? That could help me troubleshoot
the issue with our production server.


--
Chris

0

Chris Morris wrote:

Can y'all give me more information about what CVS commands are issued
during the "Checking for changes" step? That could help me troubleshoot
the issue with our production server.


I ended up writing my own cvs proxy tool to intercept the communications
since it didn't seem there was a way to get this detail out of debug
logging.

Anyway - it appears the problem does not lie with TeamCity, but with a
very slow production server. The rlog command that is run during the
"Checking for changes" simply takes a very long time, which is why I
thought things were hung.


--
Chris

0

Please sign in to leave a comment.