Problem with Gated Check-in and Clean Workspace = None

Question

Hi

 

I have a Gated Check-in build definition with the option "Clean Workspace" set to None. (The reason is that I would like to only build the relevant changes of a check-in and not the entire solution every time.)

 

The Check-in of existing files works fine.

If new files are added the first build (the one to check in these added files) works fine too.

After that the build always fails with the message: "The auto merge option is not supported for the conflict on item XXX". (XXX is either the filename of the previously newly added file, or string.Empty if there is more that one file that has been added with the previous Check-in/Build.)

Additionally to failing, the files from the shelveset that should have been checked in stay locked for edit by the service account that runs the Gated Check-in build (which is annoying if multiple checkout is disabled).

I figured out why this happens: The problem is that the Gated Check-in Build does not set the write protection of the files that have been newly added after the shelveset has been checked in. Therefore these files are writeable in the working directory and that causes the error.

 

So here my questions:

Is this not a supported configuration having a Gated Check-in Build with "Clean Workspace" set to None?

Is there any other way to only build the projects that have been affected by the changes of a Check-in? (Maybe only clean the sources not the binaries?)

 

I'm using TFS 2010 Standard Edition and the standard "Default Template.xaml" for the build definition. Multiple checkout is disabled in my configuration (but the problem also occurs if multiple checkout is enabled).

 

 

Thanks for the help

ddpommes

 

 

 

 

Answer 1

 

I found a workaround for this problem.

 

Edit the build template in the following way:

Save all local file paths of the pending changes in a variable right before the RevertWorkspace Activitiy. (string[] allLocalFiles = PendingChange.ToLocalItems(Workspace.GetPendingChanges()))

After the RevertWorkspace Activity go through all of these files and set them to ReadOnly.

 

This seems to work.

ddpommes

Answer 2

Hi ddponmmes,

Thanks for sharing your solution, which will be helpful to other community members having the similar question.

Best Regards,

Cathy

Answer 3

sorry, i can't find the place to edit as you said in the default template.xmal. can you tell me  where to edit the build template ?

Answer 4

hi,ddpommes

i don't know how to edit the build template to

"Save all local file paths of the pending changes in a variable right before the RevertWorkspace Activitiy. (string[] allLocalFiles = PendingChange.ToLocalItems(Workspace.GetPendingChanges()))"

can you give me a detailed gudidence ?

thx very much

 

Answer 5

Gated checkins with incremental builds is a supported scenario and it does work.  We do hundreds of them a day internally.

Based on the symptoms listed here, I would say that your RevertWorkspace activity is missing or failing for some reason.  Playing around with the read-only bit of these files is a bad idea.  You are merely treating the symptom and not the problem.  Worse yet, you could cause future version control operations to fail.

I also don't recommend disabling multiple checkout with gated builds.  The two are fundamentally at odds with each other.  When you tried re-enabling it, did you also log into the build machine and undo all pending changes?

Thanks,

Justin Pinnix

Development Lead – Visual Studio Team Foundation Build

Answer 6

Hi

 

To summarize the problem:

- Wo do not use multiple checkout.

- RevertWorkspace (or Undo Pending Changes) does not delete newly create files (Change: add, lock).

 

This leads to the problem that if a GatedCheckin Build fails it reverts the Changeset and leaves all newly created files in that workspace.

Together with the CleanWorkspace option = None the build server get merge conflicts if the same changeset is build again. These conflicts cannot be resolved automatically by the build server. (These merge conflicts also happen if a shelveset with newly created files is unshelved locally, after the pending changes have beed undone. The conflict says: "A writeable file with the same name exists locally." The user has to decide if he wants to keep the server or the local version, although they are identical.)

 

This is the reson causing the problem.

That the build server doesn't manage to unlock the files after the merge conflict seems to be another problem (an usually doen't happen because we do not use multiple checkout), so that's not a problem for us.

 

We use the work around (to set the readonly attribute manually) at least a year now and didn't have any problems in that time.

 

Why is it that disabling multiple checkouts and gated builds don't go together?

Should we enable multiple checkout so that gated builds work correctly?

 

Thanks for the advice.

 

ddpommes

 

 

 

Answer 7

"After the RevertWorkspace Activity go through all of these files and set them to ReadOnly."

How do you set all of these files to ReadOnly?

Cheers,

Christian

---

Cheers, Christian Fredh http://www.christianfredh.com/blog/

Answer 8

Hi Christian

I wrote an activity to do that.

The activity gets a filename as input and the code of the Execute method looks something like:

if (File.Exists(fileName))
{
  var attributes = File.GetAttributes(fileName);
  if (!attributes.HasFlag(FileAttributes.ReadOnly))
  {
    File.SetAttributes(fileName, attributes | FileAttributes.ReadOnly);
  }
}

I use the Build-In ForEach-Activity to call my own activity for each file in the pending changes.

ddpommes

Answer 9

Hi,

Thanks your the information!

Building that Activity should be pretty straightforward then. How would you enable the TFS build agent to use that Activity for the workflow? Put the dll in some folder or GAC on the build server?

Cheers,

Christian

---

Cheers, Christian Fredh http://www.christianfredh.com/blog/

Answer 10

Hi

Writing your own BuildActivity and using it is a little bit more compilcated than that, but there are many helpful tutorials how to do that.

I personally found the following post: http://blogs.msdn.com/b/jimlamb/archive/2010/02/12/how-to-create-a-custom-workflow-activity-for-tfs-build-2010.aspx very helpful.

ddpommes

Answer 11

Hi,

Thanks, got it to work with the a custom activity, and managed to resolve the issue we had. Thank you for your help!

I also got information about building the custom activity from Hugo Häggmark: http://www.hugohaggmark.com/2011/09/08/stuck-on-cannot-create-unknown-type-clr-namespace-in-tfs-build

Cheers,
Christian

---

Cheers, Christian Fredh http://www.christianfredh.com/blog/