Personal Builds cannot commit + workflow for failed personal builds

Hi,

We just started using TeamCity as an replacement for CruiseControl. One of the features we are really interested in is the Personal Build which we hoped could work similar to a gated checkin in TFS (which we also tested for a while). However, it doesnt seem to be working quite as expected.

Problem 1:
I tried making a personal build that i knew would be successful setting the option to commit if successful (we are using SVN btw). After starting the build i continued to make changes to the working copy on my local machine. A while later the personal build finished and i was shown a message in Visual Studio indicating that TeamCity failed to commit since the working copy revision was newer than the revision used for the build.

Does this mean that i cannot keep working on my machine while waiting for the personal build? If so, why would i ever do a personal build as opposed to just running the build locally? Would it help if we used git or mercurial instead (im thinking that the personal build revision could be a local commit, simply pending a push to the central vcs).

Or perhaps i misread the error messageand it refers to the working copy on the agent?

Problem 2:
Lets say i think i have finished some feature, but i made a small mistake that will cause the build to fail. I start a personal build with the option to commit. Now i proceed to start work on the next feature making a lot of build-breaking changes. While i am doing this, i get notified that my previous feature actually didnt get committed. Now i would really like to have an easy way to go back and work on the code that i submitted for a personal build, "shelving" the changes since then for a while, so that i can get the previous feature committed.

Does TeamCity support anything like this? If not, then what is the intended workflow? Perhaps relying on a DVCS that supports local commits or similar?

3 comments

Hello.
Thank you very much for feedback.

Problem 1:
I tried making a personal build that i knew would be successful setting the option to commit if successful (we are using SVN btw). After starting the build i continued to make changes to the working copy on my local machine. A while later the personal build finished and i was shown a message in Visual Studio indicating that TeamCity failed to commit since the working copy revision was newer than the revision used for the build.

There are two problems here.
First, seems message, shown to you is not clear. The correct one should told you, that "There is newer version of resource in REPOSITORY".
Two cases can lead to this:
- Repository head revision changed (somebody changed the same file and commited changes to repository) while your personal build running.
- Your working copy was not up to date, when you started personal build. Here is second problem. You have to be promted, that in this case delayed commit couldn't be performed. Today we do not have such check for Subversion (already have it for Perforce and TFS). We'll add it in the nearest future.

Does this mean that i cannot keep working on my machine while waiting for the personal build? If so, why would i ever do a personal build as opposed to just running the build locally?

Of cource you could. VS add-in have to corectly handle all kind of changes, that you could make.

Problem 2:
Lets say i think i have finished some feature, but i made a small mistake that will cause the build to fail. I start a personal build with the option to commit. Now i proceed to start work on the next feature making a lot of build-breaking changes. While i am doing this, i get notified that my previous feature actually didnt get committed. Now i would really like to have an easy way to go back and work on the code that i submitted for a personal build, "shelving" the changes since then for a while, so that i can get the previous feature committed.

Does TeamCity support anything like this?

Yes, we support this case. For all personal builds with delayed commit turned on we provide special 'Apply' action in context menu on MyChanges tool window. And it works just as you mentioned!
It really works like TFS 'Unshelve', but we did not give it this name, because we have no 'Shelve' action yet.
Today it is possible to 'Apply' only changes marked to delayed commit, but we plan to provide this feature for all personal builds.

0

Thank you for the answer.

Regarding Problem 1:

It is possible that i misread the message ( i had copied it somewhere to use in the post, but i couldnt find it again :)

Just so i understand correctly: Will any commit to the repository while my build is running prevent the commit, or is it only changes to the same files?

Regarding Problem 2:

Nice to hear this option is already present, two questions however:

1. Where exactly do i find this option? When i right-click a failed personal build i get "Commit" and "Open in Web" (the builds were started with "Commit if successful")
2. What happens with the code changes i have made since starting the personal build? After fixing the problem in the personal build i naturally want to switch back to what i was working on.

0

Just so i understand correctly: Will any commit to the repository while my build is running prevent the commit, or is it only changes to the same files?

Commit would be prevented by commiting files, sended to personal build. All other commits should not affect delayed commit.

Regarding Problem 2:

Nice to hear this option is already present, two questions however:

1. Where exactly do i find this option? When i right-click a failed personal build i get "Commit" and "Open in Web" (the builds were started with "Commit if successful")


This feature was released in our latest major release (Eluru 6.0). Seems you are trying some of the previous versions.
2. What happens with the code changes i have made since starting the personal build? After fixing the problem in the personal build i naturally want to switch back to what i was working on.

Before applying your personal change to workspace VS add-in checks all currently changed files for diff against "shelved" version. Then, if such diffs were found, VS add-in would notify you, that you could lose some of your latest changes. Here you could "shelve"(backup) you changes manually via native VCS features. We did not introduce "shelve" feature in VS add-in yet, because we just did not know, if it would be usefull for our users.

0

Please sign in to leave a comment.