Any idea when you are going to implement server side delayed commits?

Everybody in the team is just dying to have it!

Please please please



Hi Jacques,

What kind of VCS your team is using? Why do you need this feature so much? What are your real problems with the current implementation?

Kind regards,


Hi Kirill & Jacques,

Here's a simple example of how we could use the server side changing code during pre-commit: consistent code formatting applied & enforced by TC. However, this can be done without actually committing on the server side and should be in order to keep the commit with the right user and to possibly give the user a chance to revew & accept or reject the server side changes. Filed a request a while back that would cover this:

I'm curious about Jacques' use cases and wonder how it would differ from what I'm interested in.



We use subversion.

Let's talk about the deficiencies of the current client side commit:
1. Teamcity and IDE plugin have to be compatible. It may be a transient problem but not all IDEA EAPs worked with Teamcity. Hopefully IDEA VCS api won't be changed again but experience has told me that backward compatibility isn't maintained in general and most likely it will break again.
2. The client IDE must be connected.
3. I cannot change any of the files contained in a change set until the build is complete. For long build this is a very heavy restriction

Now back to the use cases:
1. Fire & Forget:
At the end of the day, I often want to commit my work just before leaving work. Without server side commit, A delayed commit can only verify that my change set did not break the build but I will have to reconnect from home or the next morning from work to have the change set committed with the chance that it will conflict with a commit done in between. A server side commit will allow me to forget about this knowing that it will be committed if the build did not break
2. Incremental work:
When dealing with big changes, or when finding little refactorings on the side of my primary task, I try to move as much out of the way (i.e. committing them) so that I keep my change set as small as possible. Small changes (small batches theory of Lean) are a good thing since they provide a smaller increment to deal with when encountering problems, reduce stress... Server side commits allow to commit a coherent snapshot of the work in progress and still be able to continue working (issue 3.) on the same files. As such server side commit will only take care of successful builds. If the build fails, there is not way to fix the problem and resubmit since the same files may have been changed already. Ideally, the IDE plugin would be able to shelve the changes made after the delayed commit was done and let the developer fix the problem, resubmit and reapply the shelved changes. Pipe dream maybe but it would be SO COOL ;)

Fire and Forget is a nice feature. However I believe Incremental Work has a much more profound impact on the efficiency of a developer. It is hard to decompose your work. This is especially true for legacy applications where refactoring are discovered at every turn: is this class name unclear? I can just change it and submit just that while keep on working... Providing this kind of support would be a HUGE bonus.
How many times did you start on a rabbit trail. How many times that little voice in your head was telling you that this is getting out of control and before too long the whole source tree will be modified and that integration will be a b***. I believe Incremental Work provides an attractive solution to this problem.

Hope this makes sense.



Your Fire & Forget scenario works presently...unless you meant to add something like that you do work on your laptop and want to take it with you once you "Fire".

>3. I cannot change any of the files contained in a change set until the build is

complete. For long build this is a very heavy restriction

Agree completely but this doesn't require a server side commit to solve, does it?



Yes I mean I can take my laptop off the network or log out of my workstation or shutdown IDEA.

You don't mean literally TW-2603 right? That issue is too restrictive since it addresses only the comment.
In my Incremental Work scenario, if I submit another build with another change on the same file contained in another ongoing build I submitted before, it should not merge these changes. The idea of Incremental Work is that I can overlay the wait time of a build and the work I am doing.
Without server side commit, I have to work serially if I want to do small changes:
1. Make first change to file 1
2. Submit client side delayed commit
3. Wait until build succeed => IDEA plugin commits file 1.
4. THEN Make second change to file 1

With service side commit, I can work asynchronously vis a vis the build/commit:
1. Make first change to file 1
2. Submit server side delayed commit
3. IMMEDIATELY Make second change to file 1
4. At some point the first build succeed and the file is committed directly by the TC server/agent without any impact on my current local work

if 3. is long (ours is not too bad 12mn but I worked on other team where the build is 1hr+... and I can't fathom how long it takes to build IDEA...), you have to work slower or take on larger change set with all the associated problems.
Believe me once you have been on multiple rabbit trails where multiple people are waiting on you and the pressure is intense, you really enjoy small batches... ;)

Does it make more sense?


Rephrase unclear second 4. (Jacques Morel)


With proper improvements to TC & its IDEA plugin, I think your 2nd scenario can work without server side commits:

1. Make first change to file 1
2. Submit server side delayed commit
3. IMMEDIATELY Make second change to file 1

-- now commit second change to file 1 before first change to file 1 is committed

4. Sometimes the first build succeed and the file is committed

About the issue, I'm referring to the "Full fix" that Yegor talks about which seems to go deeper. I still see server side commit as a separate issue of value but of value for an independent reason - basically the ability to walk away & turn off or logout of your machine.




3. I cannot change any of the files contained in a change set until the
build is complete. For long build this is a very heavy restriction

Just wanted to note. There is no such restriction. In IntelliJ IDEA you can
modify files which are currently in a delayed commit change list. TeamCity
plugin will commit those versions of these files which were on the moment of
build startup (plugin remembers content of these files when you start
delayed commit).

Pavel Sher


Interesting and in the end very ironic. The whole team has been running with the Change Bar plugin so we may have suffered from a side effect of this plugin change set conflict resolution strategy.
The plugin tells you there is a conflict by moving the conflicted into a new "conflicted" change set. Since TC plugin parks the delayed committed change set into a "Delayed commit,...) change set and activate a new change set, if you continue working on the same files the Change Bar plugin will detect a conflict and move these files in another changeset. This, TC plugin does not like at all!

Let me explore this further.


Hi Jacques,

Just got the heads up about this problem from a colleague. I had no idea TC worked with changelists this way as I haven't used it yet. I shall look at this problem for the next version - can I assume that you simply want Changes Bar to ignore TC generated changelists?



I believe it would be a good start. Hopefully it will be as simple as that ;)


I know this issue was reported a long time ago.
However, my manager has just asked why TeamCity still does not support this feature.
I have looked through recent issues but cannot find any that match the exact requirements, which are:
1. Start a 'delayed commit' build and disconnect the IDE from the TC server
2. TC performs the build and if successful, commits the changes on behalf of the user using their VCS credentials
3. When the IDE plugin reconnects to the TC server it is notified that the changes were committed and removes the change set

The main issue we have with delayed commit is needing to keep the client connected to the TC server for the changes to be committed.
We have a multi-site development team, separated by 12 hour time difference.  
If a delayed commit is started at the end of the day in TZ1 then other changes may be performed in TZ2 before the start of the next day in TZ1
which is when the delayed commit would be committed by the client - causing potential build issues and commit conflicts.

If necessary I can raise an issue for this.
Thanks, Simon.


Please sign in to leave a comment.