CVS/many dependent modules

  We have a project with many modules under the CVS root with a lot of dependencies between them. I am having a problem setting up TeamCity to trigger on changes from multiple modules. Having separate configurations for each module is not really an option, since there are about 250 modules.
  Can I setup Team City to trigger on changes in multiple modules, or somehow trick the CVS in other ways?

Comment actions Permalink

Could you please describe it in more details? Do you need to watch for changes in multiple modules? Do you have a single module which aggregates all other modules?

Comment actions Permalink

  Lets say I have modules A, B, C, and D in a CVS repository.
  D depends on A, B and, C.
  I don't want to create configurations to build A, B and C independently.
  I make a configuration for D, in which I want to trigger on changes, but not only on changes in D, but also A, B, and C. Is it possible to set this up? The only workaround I can think of is to use alias modules in CVS.

  One more minor annoyance: if I set 'VCS checkout mode' to 'do not check out files automatically' I cannot get a trigger even on changes in D. I think that that should work...

Comment actions Permalink

What version of TeamCity do you use? Is it possible to send your modules file to teamcity-feedback[at] with details on which module changes detection does not work? We will try to reproduce this locally.

Comment actions Permalink

We use 5.0.3 (build 10821).
I do not think there is a bug in TeamCity. It is more likely to be a lack of feature, or my not understanding how to set it up properly.

Comment actions Permalink

You mentioned that you want to trigger build on changes in A, B, and C, but how do you want to checkout files? Do you need the files from A, B and C on agent?

If yes, then you can specify . (dot) as module name in VCS root settings and choose appropriate modules with help of checkout rules, smthg like:

With such setup on the agent, in checkout directory you will see:
<root> (content of the module D)
A (A module)
B (B module)
C (C module)

i.e. content of the module D will be placed into the root of checkout directory, while A, B and C will be checked out into corresponding subdirectories.

Comment actions Permalink

  Well, I don't want to do any directory shuffling. It is ok if all of them are in their own directories in root.
  What I am trying to do is create a most efficient way of checking what has changed and triggering the corresponding builds only, if possible.

  In this repository, there are about 200 modules (similar to A, B, C in my example above). About 20 of those have dependencies on many others (we can call them D1, D2... D20 just to be consistent with previous discussion).

  Now, as far as I understand, I have three options:
  1. Have one VCS root that triggers on any change, and put all the dependencies inside the configurations' trigger rules. This becomes messy when dependencies change.
  2. Set up 20 VCS roots using CVS aliases, and don't create any trigger rules. Also a lot of work creating all the roots, and have different configs use different roots.
  3. Have one VCS root, don't create any trigger rules, and build everything all the time. Let the build figure out what it needs to do. This seems to involve the least amount of work setting up configurations, but it will needlessly trigger builds.

  Any thoughts?

Comment actions Permalink

Hello Ivan,

Have you found the solution to your question?

Kind regards,


Please sign in to leave a comment.