VCS changes showing up more than once when using SVN externals.

Hi,

I have a TeamCity project set up using Subversion as a VCS.  I have one VCS root and that root has several externals defined.  Everything works fine, but my pending changes and changes for a build seem to be showing up more than once in the UI.  I use one SVN repository for all my modules.  For example:

- module 1
- branches
- tags
- trunk
- module 2
...
- module 3
...
- maven parent module
- external --> module 1
- external --> module 2
- external --> module 3

I know I should really have each module set up as a separate project and that's eventually what I will do.  However, I'd prefer to let TeamCity checkout and build my parent project for the short term.  It seems like the changes listed in the UI get listed once for every external location that is affected by a commit.  For example, if I refactor some code and it affects modules referenced by 3 different externals I'll see that change 3 times in the TeamCity UI.

I know this is an issue that will go away as my development cycle matures and I improve my build configurations, but I'm wondering if there's a way for me to get TeamCity to recognize that it's listing changeset #NNN more than once?

Edit: I've seen this error in my logs, but it showed up in the UI today.  I think it's related:

Failed for the root 'JP Tech Main SVN Repo' #8: Error executing query with params:[707, ryan, Starting to try to set up an OSGi bundle for the Glassfish DAO provider., 1248978939674, 8, 2, 131_2009/07/30 12:35:40 -0600, 131, 6]; uncategorized SQLException for SQL [INSERT INTO vcs_history (MODIFICATION_ID, USER_NAME, DESCRIPTION, CHANGE_DATE, VCS_ROOT_ID, VCS_ROOT_VERSION, VERSION, DISPLAY_VERSION, CHANGES_COUNT) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)]; SQL state [23505]; error code [0]; ERROR: duplicate key value violates unique constraint "vcs_history_pkey"; nested exception is org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "vcs_history_pkey            


The error was only in the UI for less than a minute, then it went away.

TIA,
Ryan

4 comments
Comment actions Permalink

Hello Ryan,

  Do I understand correctly that this problem occures when you change a file which is included several times into the source tree?
  In this case, this file will have different paths so you see several changes in TeamCity, and I believe this is correct behaviour.

  In general, if the changes relate to the same repository and have the same changelist ID they should be shown once.

  Could you probably provide some screenshot which would illustrate the problem?

  Regards,
  KIR

0
Comment actions Permalink

Hi Kirill,

Thank you for your reply.

Before you get to my screenshots I'm going to say that I have a decent idea of what's causing my problem (and it could very well be me).  I've just finished breaking my codebase into maven modules.  I switched to a single subversion repository which contains all of my modules.  At the moment I have TeamCity set up to checkout a parent maven project using subversion externals to pull in all the required sub-modules.  Then I let TeamCity build the entire parent project including all sub-modules.  Is this an acceptable approach or should I be setting up one build configuration per maven module?

The reason I'm letting TeamCity build my parent project for now is that I still make the odd refactoring change that affects multiple modules.  Is there any 'best practices' type documentation you could point me towards?

Here are some screenshots that should give you a better idea of what I mean.  I've tried to crop them and highlight only the relevant areas.  I uploaded them to an external image host before I realized your forums support images.  Let me know if you'd like them uploaded using the forum instead.  I'll explain them inline.

http://hdimage.org/images/v443l5b9yb7h5rutsq1.png

This is an image of my pending changes.  The portion highlighted in blue represents revision 131 in my VCS.  The portion highlighted in red represents revision 129 in my VCS.  You'll notice the portion in red shows the changes twice.


http://hdimage.org/images/dxes2ta34rgcbkpea4tk.png

This image shows what is listed under 'My Changes' for revision 131.  I believe these changes should show up twice since one of the files affected is included in both build configurations I have set up.


http://hdimage.org/images/6ivtvbyqti1w5w73093.png

This is an image of my Subversion VCS for revision 131 and shows all of the files that were involved in the revision.


http://hdimage.org/images/okocihms3oj1k87n5tl.png

This images shows what is listed under 'My Changes' for revision 129.  I believe these changes should also be listed twice rather than 4 times.


http://hdimage.org/images/j2odbf41pnna07i1d28v.png

This image shows my actual VCS changes for revision 129.  The paths highlighed in red represent different maven modules.  I will eventually give each module its own build configuration.

I mentioned before that I suspect it has something to do with the way I've set up my externals.  I use subversion externals to aggregate all of the modules I need for a specific project.  For the three modules shown in the last screeshot, my externals look something like this:

^/itma/itma-car/trunk/itma-car/ itma-car
^/itma/itma-dao-glassfish-provider/trunk/itma-dao-glassfish-provider itma-dao-glassfish-provider
^/itma/itma-model/trunk/itma-model itma-model


I have TeamCity set up to checkout all externals and have a build configuration set up to build using a maven parent pom.

0
Comment actions Permalink

Hello Ryan,

  I'm sorry for a large delay with the answer - I was on vacation.

  In general, your setup looks quite valid, and I see no fault from you side.

  I've investigated your situation and tried to reproduce it. Unfortunately, no luck. If you use a single VCS root for your build configuration, all the parts of a change should merge together.
  In my configuration, I have a single VCS root with the following checkout rule:

  JavaTest/trunk => .

  JavaTest/trunk has externals, like:

  svn://localhost/test      test_externals
^/JavaTest/trunk/files    test_externals2

  If I commit a change with files from /JavaTest/trunk/files and from svn://localhost/test, I still get a single change in the changes popup. Please note, that first external refers ouside of project tree, and the second externals refers inside project tree, and still only one change is detected.

  Do you have any checkout rules defined in your configurations? Do you reuse the same VCS root between your build configurations?
  Could you probably enable VCS debug logs and provide them privately via e-mail to kirill.maximov%jetbrains.com?

  Kind regards,
  KIR

0
Comment actions Permalink

Hi Kirill,

Thanks for the reply.  I've changed the structure of my subversion repo a fair bit since I made this post.  I've also set up each module with a build configuration in TeamCity and started using checkout rules (I wasn't using checkout rules before).  Things are working a lot better for me.  I'm satisfied to blame my problems on having a poor VCS structure.  I'm content with how things are working at the moment and don't expect you to investigate any further.  I'll recap the VCS structures I was using and the VCS structure I'm using now, just in case it's useful to anyone else that may have similar issues in the future.

When I was having difficulty I had two very similar setups and only one of them exhibited the behaviour I described.  With the structure that gave me trouble I had a parent module with externals pointing to several child modules in the same repository.  I was using a single VCS root (without checkout rules) that pointed to the parent module directory and checked out everything including externals:

my-project-name

my-parent-project

trunk

my-parent-project (has externals to child modules)

child-module-1

trunk

child-module-1

child-module-2

trunk

child-module-2



A very similar setup, but not producing duplicate VCS changes looked like this:

my-parent-projects

my-parent-project

trunk

my-parent-project (has externals to child modules)
my-project-modules

child-module-1

trunk

child-module-1

child-module-2

trunk

child-module-2


I scrapped (refactored) both of the above VCS structures in favor of something like this:

branches

assemblies

modules

projects
tags
...
trunk

assemblies

my-assembly-1

modules

my-module-1

my-module-2

my-module-3

projects

my-project

modules (externals here - easy to ignore with checkout rules)


The 3rd structure is much easier to deal with (and maintain).  It also makes it a lot easier when writing checkout rules for TeamCity (ie: +:modules/** is much easier than writing one rule per module in the old structures).

BTW, I was pretty impressed when I finally set up one build configuration per module for my project.  Checking in some code and watching TeamCity do it's thing is pretty cool.  I swear I wasted an hour checking in minor code changes and watching TeamCity calculate / execute build chains ;-)

One thing I'd love to see in a future version would be the ability to have TeamCity automatically set dependencies based on Maven poms.

Thanks for the help,
Ryan

0

Please sign in to leave a comment.