TeamCity - SVN update mechanism, locally modified files

Hello,

I have a question about the way that SVN updates work within TeamCity, but just to give you a bit of context to my question...

-          We have TeamCity Enterprise 7.1.5 (build 24400) environment. We have a quite a large number of mainly .Net based Builds.

-          All VCS Roots, which is SVN  based, are configured to be checked out Automatically on server.

-          Some of the TeamCity Build Configs take quite a large amount of time to complete. The ‘build’ part is generally quite quick, it’s updating the VCS source that takes up time, sometimes 15 minutes out of a total of about 20 minutes, so its disproportionately high. In order to be sure that the build is clean, we have set the Clean all files before build: ON. Of course this results in the poor performance that I have described above. So I am trying to optimise the Build Configs and reduce the amount of time TeamCity spends refreshing the VCS roots.

Some of the areas I am looking at is....:

- I have installed the Swabra plugin and configured it as follows:

     o   Files cleanup: After build finish

     o   Clean Checkout : False

     o   Lock Processes: Report

     o   Paths to monitor: <Empty>

     o   Verbose output: True

- When I run it, I can see that the build generates a number of files (Dll, Exe, MSI, etc) and Swabra successfully detects and deletes them at the end of the build. So far I have not seen any Tracked files get deleted by any build. However there are a few tracked files that get modified. From my understanding, Swabra itself cannot recover the modified files. Also because the checkout takes place on the Server and not the Agent, the ‘svn revert’ option would not work.


So to come back to my original question: How does svn update work in TeamCity when dealing with tracked files that been modified locally and the checkout is taking place on the TeamCity Server rather than the Agent. If the modified file gets updated in svn, will that be correctly updated in the TeamCity Build Config or will it leave the modified file.

Many Thanks in advance for any help,

RG

5 comments
Comment actions Permalink

Hello,

   You've described the situation rather accurate - if your builds modify files stored in SVN, there is no effective way to restore them if you're using server-side checkout.
   My question is, why don't you use agent-side checkout?

   Regards,
   KIR

0
Comment actions Permalink

Hello Kir,

Thanks for your response.

The main reason that we do not use Agent-Side checkout is the size of the repository. It is pretty huge and we make extensive use of checkout rules to limit the scope of what's downloaded. With agent-side checkouts the exclude rules are only applied after a full checkout, in addition the .svn content that is also download. This increases the storage requirements quite significantly and thus reduces the capacity on the Build Agent. The consequence is that more Checkout folders get cleaned up due to the reduced amount of space.

After your reply I did some experiments with agent-side checkouts to get a benchmark. For our situation, I found that a clean checkout takes almost 3X longer with the agent-side checkout, as well as requiring 2X the storage capacity. I also noticed that the 'svn revert' step on an agent-side checkout takes about 60% the time of a clean checkout on a server-side checkout. So overall we are not really seeing a significant gain.

Going back to my original questions, I have two possible scenarios...
1.
- During a build, some tracked files get modified within the checkout folder
- Those files are not modified within SVN and so are not reverted back to the original version during future builds
   I am OK with this situation because whatever modifies the files in the initial build will also modify the file in subsequent builds
2.
- During a build, some tracked files get modified within the checkout folder
- Those files are modified within SVN and on subsequent builds, they should get updated with the latest version from SVN
   Could you please clarify the behaviour of TeamCity in this scenario. Without a full clean checkout, will those updated files overwrite the locally modified files

Thanks again for your help,

RG

0
Comment actions Permalink

Hello,

    I see, thanks for the explanation.

    In your second scenario, the files modified in VCS will overwrite locally modified files in the working copy.
    So I think you should be on the safe side.

    Regards,
    KIR

0
Comment actions Permalink

Hello Kir,

Thanks again for your response.

It certainly looks like TeamCity behaves in an appropriate way for our requirements.

I do have a request for feature / functionality update in the way Swabra plugin works (if that is possible)...

Currently, Swabra has the option 'Force clean checkout if cannot restore clean directory state'. In our situation, we can not use it because we have modified files which would trigger the cleanup. Even though our builds so far do not delete any tracked files, it may happen in the future and in that scenario we would need a clean checkout.

So the feature request is to provide more options for the Clean Checkout in Swabra:

- Force clean checkout if cannot restore clean directory state (the original option)

- Force clean if tracked files are modified

- Force clean if tracked files are deleted

This would give use flexibility we need to shorten our build times but at the same time ensure that are Checkout are correct.

Many Thanks for your help,

Rishabh

0
Comment actions Permalink

Rishabh,

I've created an issue in or tracker, feel free to watch and vote http://youtrack.jetbrains.com/issue/TW-31257

As a dirty workaround: if the list of such "normally modified by the build" files is available and immutable, you may try adding the following rule for each of them in "Paths to monitor" Swabra settigns section and enable "Force clean checkout if cannot restore clean directory state"

-:<checkout directory relative path rules>
0

Please sign in to leave a comment.