Confusing changeset behavior doing a Remote Run from eclipse with SVN


We just started using TeamCity here, and one of the features we were most excited about after working with CruiseControl for years was the remote run.

After trying it a few times, it's just about as cool as we hoped, but I did hit one problem that was at least confusing, if not a bug, and I wanted to know what expected behavior is.

The way I want to use remote run is to make a change, tell TeamCity to run the suite and commit if successful, and while it's off doing that revert to HEAD on my machine so I can start working on something else.  Let's say HEAD is r1.  I make my first set of changes and tell TC to remote run, then revert back to r1.  Now I start another set of changes.  While I'm doing that, TC finishes it's remote run, and commits the result as r2.

I would now expect to have to update my local working copy, and possibly merge any r2 changes in to my local copy.  Instead, what appears to happen is that my local copy is marked as if it's r2, but without actually bringing in the r2 content.  When I committed, I didn't get any notification that I had a conflict, instead the r2 changes were effectively reverted!  I assume I have some local setting wrong, but so far haven't been able to find it.

Can someone tell me how this is supposed to work?  Bug, or user error?




Hi Chris,

A Delayed Commit after successful executed Remote Run does not change actual content o local resources(it hidden for user at least).
You can restore your workspace to time of Remote Run with action "Apply changes to workspace" of "TemCity Changes" view.



Yeah, my concern is the hidden from the user part.

I think of this feature as primarily letting me continue working on other things while a full test run is in progress.  In order for that to work cleanly with regards to the RCS, I would think the remote run has to take a patch, and (assuming success) at commit time apply that patch to whatever revision it was taken from then commit.  If it's using my local working copy in some way to do that commit, then it's going to incorrectly pick up work that's not complete yet.

Thanks for the info, I think I'll log an enhancement.


This is also posted as TW-13160, but since it might be not a bug, let's continue here.


Actually, committing from the working copy is as designed behavior and this is done so for a reason.

When TeamCitycommits a verified personal change, it backs up the current changes, restores the content of the files that were sent to the personal build, commits them and then restores the local files back.

This way you do not need to merge your current changes with the verified changes, you just continue working and if the changes are OK, they are committed as if they were comitted at the time of the personal build initiation.

I understand that you try to use a bit different approach that is more like committing into a branch and then merging between the verified and your current branch. However, this seems like introducing an item more to think about when doing a personal build.

Can you describe why the approach used by TeamCity does not suit your needs?


The question is, what state does TeamCity leave my SVN workign copy in after the commit?  Take this scenario:

- I make changes to the r1 of a file, and send it off to do a personal build.
- I rollback in my local working set, and do more changes on the r1 version of the file.
- The personal build finishes, and does the commit as you describe
- I check in my second set of changes

In the last step, does SVN think I'm checking in changes to the r1 of the file (which would necessitate me doing some merges or conflict resolution) or changes to r2 (which, unless TeamCity had merged in the r2 changes to my workign set, would overwrite the r2 changes).  That depedns on what state TeamCity leaves the working copy in after the commit.  I think that either the working copy has to be left in the state such that I'm editing r1, or TeamCity has to do a real SVN merge of the personal changes to the local copy, and let me know if there's conflicts to be resolved.  Because if it's putting me in a position that r2 could get easily and accidentally overwritten, that would be bad.


Just realized, maybe I'm missing your assumption about the use case.  Do you expect that when a user runs a personal build, then continues working, that they very specifically do NOT revert the changes that the personal build is running?

My problem with that assumption is that it reduces the developer's flexibility.  If some new bug comes up that they need to tackle, they should be able to switch to whatever branch or revision they need to, without worrying about the personal build that's running already.



You are right here, the assumption is that user does NOT revert the code after sending a file to remote run.

From your example (update to r1, change, send remote run, revert to r1, make other changes), when the remote run succeeds, the remote run change is committed as r2 and then working copy is based on r2, but the content of the files corresponds to the "other" changes made. So, yes, if you revert after sending remote run and then commit your new changes you have the risk of overriding the first change sent via remote run with the later changes.

> My problem with that assumption is that it reduces the developer's flexibility.  If some new bug comes up that they need to tackle, they should be able to switch to whatever branch or revision they need to, without worrying about the personal build that's running already.

I understand the approach and it is indeed not an anticipated one when you use TeamCity's remote run.
However, TeamCity's current approch is chosen on purpose since it seems to reduce necessity to merge (b'cause you need to merge a lot if it were the way you suggest it). Your approach seems to be a way to go with branching-friendly version controls like Git or Hg, but our impression is that continuous merging is a pain with Subversion and alike and we try to minimize necessity for the merge.

All in all you seems to be asking for server-side pre-tested commit that we are well aware of but I am not sure whether is it going to materialize in forseeable future (for all the same reasons: it will force developers to merge with own earlier changes).


Yeah, server side commit would do it.  In fact, that's how I originally thought this feature would work, although I can understand that there's some complexity with it (how to handle conflicts, you'd want to be using the client's credentials to do the check in so that it's logged as 'my' changes, etc).  I think that would a really good addition to the product, and would really simplify the use case by letting the developer fire off the changes and move on to whatever else is on his/her plate.

But even if you continue to do it locally, I think you're overestimating the merge pain with SVN.  It actually does a really good job of automatically merging when it can't, and complaining to the user when it can't, so I'd encourage you to take a look at simply doing the following when the remote run finishes in a passed state:

- Take a patch of the current working copy.
- Do an SVN switch to the revision that the remote run changeset was based on.
- Commit.
- SVN switch to the revision that the working copy was based ont.
- Apply the temporary patch

In this case, if the temporary patch has no conflicting changes, then the user wouldn't even notice.  If it did, they'll have to take care of it.

There's still some problems with this approach, which I imagine the current one has as well, which is that you really need to lock access to the working copy while you're doing all this...  But I imagine you've dealt with that already.

In the end, the big problem here is that the potential for silently overwriting commited changes is really dangerous.  Test probably won't even fail to make you notice, because there's a good chance that any that would fail would've gotten overwritten as well, which is really problematic.  For that reason, I do think you should have this on the list as a bug or enhancement.



OK, makes some sense. I've changed the issue to reflect this suggestion. Seems it should be confurable...

Let's see how popular the issue will be in terms of votes and comments.


Please sign in to leave a comment.