{"id":4063,"date":"2006-03-20T22:32:00","date_gmt":"2006-03-20T22:32:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/buckh\/2006\/03\/20\/how-to-check-in-changes-on-behalf-of-other-users\/"},"modified":"2006-03-20T22:32:00","modified_gmt":"2006-03-20T22:32:00","slug":"how-to-check-in-changes-on-behalf-of-other-users","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/buckh\/how-to-check-in-changes-on-behalf-of-other-users\/","title":{"rendered":"How to check in changes on behalf of other users"},"content":{"rendered":"

Recently someone asked how to check in changes for another user.  There are at least two good scenarios where this is needed.  One is for check-in systems such as the Gauntlet system we used internally during the development of TFS.  Rather than check in directly, developers would shelve their changes and put them in the Gauntlet queue.  Gauntlet would unshelve one shelveset’s worth of changes, build the code with those changes, run a small set of tests, and then check in the changes on behalf of the user who created the shelveset.<\/p>\n

Another important scenario is for converting an existing system over to Team Foundation Server.  For version control, you would like the history in TFS to reflect who actually made the changes, rather than the account used for the conversion.<\/p>\n

We provide the capability to support these scenarios through a permission and parameters to the CheckIn()<\/font> method, which supports the \/author<\/font> option on the checkin command in tf.exe.  In order to be able to check in changes on behalf of another user, the user performing the check in must either be an administrator or must have the CheckinOther permission.<\/p>\n

The MSDN documentation describes the CheckinOther permission<\/a> and how to set it from within VS as well as from the command line.  From the command line, you would execute something like the following.  This example sets the permission for $\/Project and all directories and files that inherit permission settings from $\/Project.<\/p>\n

\n

tf perm $\/Project \/allow:CheckinOther \/user:domainSomeOne<\/font><\/p>\n<\/blockquote>\n

From the command line, you can check in changes for someone else by using the \/author<\/font> option to the the checkin command (documentation<\/a>).  For example, the following command checks in all changes in your current workspace on behalf of OtherUser (\/author:domainOtherUser<\/font>) without prompting (\/i<\/font>).  You will need to specify domain if it is different than the domain of your user name (there’s no harm in always specifying it).<\/p>\n

\n

tf checkin \/i \/author:domainOtherUser<\/font><\/p>\n<\/blockquote>\n

One important thing to note here is that the changes are pending in your workspace and are being checked in from your workspace.  You are simply specifying what user name you want to see in the brief history format.  Both your user name and OtherUser are recorded in the changeset data, so that you can always determine who checked in the changes.<\/p>\n

All of the above discussion also applies to the CheckIn()<\/font> method on the Workspace<\/font> class in the version control API.  I have copied the method signature and its documentation below.  The overload below is the one that takes all of the parameters.  The simplest CheckIn() overload requires only two parameters, an array of PendingChange<\/font> objects and a comment, and it is used in the basic version control API example<\/a>.<\/p>\n

    \/\/********************************************************************************************<\/span>
    \/\/\/ <summary><\/span>
    \/\/\/ Check in a set of pending changes.  Checkins are atomic – either they all succeed or<\/span>
    \/\/\/ they all fail.  If there are any conflicts that need to be resolved before the check in, the check<\/span>
    \/\/\/ in operation will throw an exception.<\/span>
    \/\/\/ If any part of the operations leading up to the final check in commit fail (uploading<\/span>
    \/\/\/ files, etc) then the operation is aborted and an exception is thrown.  If updating client<\/span>
    \/\/\/ or work item state fails after the commit operation, a non-fatal error is reported with the<\/span> 
    \/\/\/ actual checkin having been successfully committed.<\/span>
    \/\/\/ <\/summary><\/span>
    \/\/\/ <param name=”changes”>List of changes to check in.<\/param><\/span>
    \/\/\/ <param name=”author”>if non-null, this identity will be listed in history for the committed<\/span>
    \/\/\/   changeset (note that the user running this operation must have the CheckinOther<\/span>
    \/\/\/   permission)<\/param><\/span>
    \/\/\/ <param name=”comment”>Comment to go along with the checkin.<\/param><\/span>
    \/\/\/ <param name=”checkinNote”>Any applicable checkin notes data.<\/param><\/span>
    \/\/\/ <param name=”workItemChanges”>List of work item changes to occur with this checkin<\/param><\/span>
    \/\/\/ <param name=”policyOverride”>if non-null, policy failures are being overridden<\/param><\/span>
    \/\/\/ <param name=”checkinOptions”>Per-checkin options that affect event generation and<\/span>
    \/\/\/ checkin author validation<\/param><\/span>
    \/\/\/ <returns>changeset number created by checking in<\/returns><\/span>
    \/\/********************************************************************************************<\/span>
    public<\/span> int<\/span> CheckIn(PendingChange[] changes, String author, String comment, CheckinNote checkinNote,
                       WorkItemCheckinInfo[] workItemChanges, PolicyOverrideInfo policyOverride,
                       CheckinOptions checkinOptions) <\/p>\n

    [System.FlagsAttribute()]
    public<\/span> enum<\/span> CheckinOptions
    {
        None = 1<\/span>,
        ValidateCheckinOwner = 2<\/span>,
        SuppressEvent = 4<\/span>,
    }<\/div>\n

The author<\/font>, checkinNote<\/font>, workItemChanges<\/font>, and policyOverride<\/font> parameters can all be null<\/font> if you don’t have values to specify (okay, the comment<\/font> can be null<\/font> too, but you wouldn’t do that, right?).<\/p>\n

The CheckinOptions values allow you to control what happens with the author<\/font> parameter (ValidateCheckinOwner<\/font>) and server-side event generation (SuppressEvent<\/font>).  For overloads of CheckIn()<\/font> that don’t specify the checkinOptions<\/font> parameter explicitly, the value CheckinOptions.ValidateCheckinOwner<\/font> is used.<\/p>\n

For a Gauntlet-type scenario, calling the Checkin()<\/font> method with the author<\/font> being the owner of the shelveset is exactly what you need.  You can call an overload that doesn’t explicitly specify the checkin options and use the default value.<\/p>\n

The real purpose of the checkinOptions<\/font> parameter is to support version control converters.  For that scenario, you may need to check in changes on behalf of users that don’t exist as Windows users, either because they have been deleted or because the old version control system had its own user security system (e.g., Visual SourceSafe).  So, most converters will not want to have the server validate the checkin owner (author).<\/p>\n

Also for the conversion scenario, you will likely want to suppress checkin events on the server.  The reason is that you are likely creating hundreds or thousands of changesets, and checkin event generation will simply add overhead to a process that you’d like to have run as quickly as possible.  To do this, you will want to specify CheckinOptions.SuppressEvent<\/font> for the checkinOptions<\/font> parameter.<\/p>\n

Putting this all together, the call to CheckIn()<\/font> in a version control converter might look like the following.  You may also want to specify the old system’s checkin date and other metadata in the checkin comment.<\/p>\n

\n

PendingChange[] pendingChanges = workspace.GetPendingChanges();<\/p>\n

String oldSystemUser = \/* get user name from other VC system *\/;
<\/font>
workspace.CheckIn(pendingChanges, oldSystemUser, “converted changeset”, null, null, null, CheckinOptions.SuppressEvent);<\/font><\/p>\n<\/blockquote>\n

For those of you wondering why CheckinOptions.None<\/font> and other None enum values have the value of 1 rather than zero, it was a side effect of wsdl.exe.  In SOAP, the enumeration values are marshalled as names, such as None, rather than integers.  As a result, the values of the enumerations in the client may not match the values of the enumerations used by the server, since they are specified in the web service’s WSDL.<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

Recently someone asked how to check in changes for another user.  There are at least two good scenarios where this is needed.  One is for check-in systems such as the Gauntlet system we used internally during the development of TFS.  Rather than check in directly, developers would shelve their changes and put them in the […]<\/p>\n","protected":false},"author":94,"featured_media":10268,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[6,8],"class_list":["post-4063","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-source-control","tag-team-foundation"],"acf":[],"blog_post_summary":"

Recently someone asked how to check in changes for another user.  There are at least two good scenarios where this is needed.  One is for check-in systems such as the Gauntlet system we used internally during the development of TFS.  Rather than check in directly, developers would shelve their changes and put them in the […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts\/4063","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/users\/94"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/comments?post=4063"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts\/4063\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/media\/10268"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/media?parent=4063"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/categories?post=4063"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/tags?post=4063"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}