{"id":4073,"date":"2006-03-20T18:46:00","date_gmt":"2006-03-20T18:46:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/buckh\/2006\/03\/20\/how-to-validate-check-in-policies-evaluate-check-in-notes-and-check-for-conflicts\/"},"modified":"2006-03-20T18:46:00","modified_gmt":"2006-03-20T18:46:00","slug":"how-to-validate-check-in-policies-evaluate-check-in-notes-and-check-for-conflicts","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/buckh\/how-to-validate-check-in-policies-evaluate-check-in-notes-and-check-for-conflicts\/","title":{"rendered":"How to validate check-in policies, evaluate check-in notes, and check for conflicts"},"content":{"rendered":"

In the version control API, the CheckIn()<\/font> method does not evaluate check-in policies and validate check-in notes.  It provides with the ability to supply both an override comment and check-in notes, as applicable, but the evaluation and validation must have been performed prior to calling CheckIn()<\/font>.  The reason for this is that in a real-world application, you will evaluate check-in policies and validate check-in notes at points in time that make sense for whatever you are writing.  For example, the Visual Studio environment will evaluate check-in policies when certain events are triggered.  Also, applications that are converting from a different version control system to TFS will want to bypass these checks.<\/p>\n

The EvaluateCheckin()<\/font> method evaluates policies and validate check-in notes.  It also checks for conflicts.  Here is the method signature along with its documentation.<\/p>\n

    \/\/********************************************************************************************
    \/\/\/ <summary>
    \/\/\/ Evaluate the changes to see if they are ready for checking in.
    \/\/\/ <\/summary>
    \/\/\/ <param name=”options”>Selects what to check (notes, policies, conflicts).<\/param>
    \/\/\/ <param name=”allChanges”>All pending changes for the workspace (needed by checkin policies).
    \/\/\/ <\/param>
    \/\/\/ <param name=”changes”>List of changes to evaluate.<\/param>
    \/\/\/ <param name=”comment”>Comment to go along with the checkin.<\/param>
    \/\/\/ <param name=”checkinNote”>Any applicable checkin notes data.<\/param>
    \/\/\/ <param name=”workItemChanges”>List of work item changes to occur with this checkin (supplied to checkin policies).<\/param>
    \/\/\/ <returns>the results of what was checked<\/returns>
    \/\/********************************************************************************************
    public CheckinEvaluationResult EvaluateCheckin(CheckinEvaluationOptions options,
                                                    PendingChange[] allChanges,
                                                    PendingChange[] changes,
                                                    String comment,
                                                    CheckinNote checkinNote,
                                                    WorkItemCheckinInfo[] workItemChanges)<\/font><\/p>\n

The options<\/font> parameter controls what is evaluated and is a simple flag enum.<\/p>\n

    \/\/********************************************************************************************
    \/\/\/ <summary>
    \/\/\/ Used in pre-checkin evaluation, this enumeration is used to specify which aspects of a
    \/\/\/ checkin should be evaluated.
    \/\/\/ <\/summary>
    \/\/********************************************************************************************
    [Flags]
    public enum CheckinEvaluationOptions
    {
        Notes = 0,
        Policies = 1,
        Conflicts = 2,
        All = -1,
    }<\/font><\/p>\n

The result of the function is a CheckinEvaluationResult, which has the following properties.<\/p>\n

    \/\/********************************************************************************************
    \/\/\/ <summary>
    \/\/\/ These are the checkin conflicts returned by the server.
    \/\/\/ <\/summary>
    \/\/********************************************************************************************
    public CheckinConflict[] Conflicts<\/p>\n

    \/\/********************************************************************************************
    \/\/\/ <summary>
    \/\/\/ These are the checkin note problems (missing required notes, invalid checkin notes, etc.).
    \/\/\/ <\/summary>
    \/\/********************************************************************************************
    public CheckinNoteFailure[] NoteFailures<\/p>\n

    \/\/********************************************************************************************
    \/\/\/ <summary>
    \/\/\/ These are the checkin policy failures.
    \/\/\/ <\/summary>
    \/\/********************************************************************************************
    public PolicyFailure[] PolicyFailures<\/p>\n

    \/\/********************************************************************************************
    \/\/\/ <summary>
    \/\/\/ If evaluating policies throws an exception, this is the exception that occurred.  It is null
    \/\/\/ otherwise.
    \/\/\/ <\/summary>
    \/\/********************************************************************************************
    public Exception PolicyEvaluationException<\/font><\/p>\n

The properties will be set according to the options you specify and according to what fails.  So if you don’t request policy evaluation, for example, or there are no policy failures, the PolicyFailures property will be an empty array.<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

In the version control API, the CheckIn() method does not evaluate check-in policies and validate check-in notes.  It provides with the ability to supply both an override comment and check-in notes, as applicable, but the evaluation and validation must have been performed prior to calling CheckIn().  The reason for this is that in a real-world application, […]<\/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-4073","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-source-control","tag-team-foundation"],"acf":[],"blog_post_summary":"

In the version control API, the CheckIn() method does not evaluate check-in policies and validate check-in notes.  It provides with the ability to supply both an override comment and check-in notes, as applicable, but the evaluation and validation must have been performed prior to calling CheckIn().  The reason for this is that in a real-world application, […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts\/4073","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=4073"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts\/4073\/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=4073"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/categories?post=4073"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/tags?post=4073"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}