"Restrict the Scope of a Check-in Policy" does not work as documented/expected

Question

Using check-in policies in TEE, we would like to exclude certain type(s) of files from being checked.

The feature "Restrict the Scope of a Check-in Policy" matches the requirement (although it works by specifying the files to be included rather than excluded).

However, using as test pattern the first one specified in the documentation (.*\.java$) we have the following unexpected behaviour:

1. Using full paths from two different files in the validation GUI the pattern works as expected (i.e. a java file will be checked and a xml file will not)
2. "Actual" Check-in of "XML" or "java" file does not make any difference: BOTH have the policy applied (when only "java" should)

Any idea what could cause this behaviour and/or what is needed to achieve the expected result?

For reference, the TFS plugins configured and their versions on one of our test workstations (similar behaviour occurs on two different workstations with different flavors of Eclipse):

---

Christian De.

Answer 1

Are you creating a new check-in policy or using one of the built-in policies?  Also, which platform are you running on?

I'll try to reproduce the problem.

Thanks,
Rick

Answer 2

I tried a quick test using the built-in Sample check-in policy.  It correctly excluded a .xml pending change and included a .xml change.

The sample has the following line of code in SamplePolicy.evaluate...

final PendingChange[] checkedChanges = pc.getPendingChanges().getCheckedPendingChanges();

The filtering occurs in "getCheckedPendingChanges()".  Are you using getCheckedPendingChanges() in your policy?

Thanks,
Rick

Answer 3

Rick,

let me clarify as asked:

• Are you creating a new check-in policy or using one of the built-in policies? 

We intend to use the plain vanilla built-in "Work Items" check-in policy. We do NOT create or use any custom policy

•  Which platform are you running on?

The platform is OS: Windows XP SP3 and TEE "host" is "STS" or Websphere" flavors of Eclipse

• Quick test using the built-in Sample check-in policy?

From your last answer, it is not clear if your test was conducted by defining such an "inclusion" pattern. The feature we use is  "Restrict the Scope of a Check-in Policy".

Christian

---

Christian De.

Answer 4

Thanks for the clarification.

The scopes are inclusion scopes and policy scoping applies to the pending changes in the check-in.  However, the "Work Item" check-in policy doesn't check if there are any pending changes that are in scope.  It only checks to see if there are any checked work items associated with the check-in.

So setting a scope on the "Work Item" policy will have no effect (as you have observed).

Hope this helps.
Rick

Answer 5

Rick,

your proposed answer indicates that this behavior is apparently "by design", which I can accept (if a bit grudgingly).

However, my point is that it "does not work as documented/expected ", which is even more so if it is by Design !

The documentation does not make any mention whatsoever of the fact that one or more policies would not have the scope inclusion applied. The following phrase in the documentation is a bit ambiguous:

"In Team Explorer Everywhere, you can restrict the scope of a check-in policy to control to which files the policy applies. "

From your answer, this implies that you can only use the "Restrict scope" feature to policies which have "files (to which) the policy applies".

So most policies could not use that feature: "Builds", "Changeset Comments", "Work Items", "Work Item Queries".

Do you confirm this interpretation?

Thanks,

---

Christian De.

Answer 6

Yes, you are correct.  Scoping will have no effect on policies which do not consider pending changes as part of the policy criteria.

I can certainly see how this is confusing.  The documentation does not make it clear that some of the built-in policies "Check for Comment", "Work Item", and "Work Item Queries" are not affected by a scoped set of pending changes.

Perhaps the UI shouldn't offer the scoping option if a policy doesn't consider the scoped set of changes, or all policies could consider the set of scoped changes and be defined to pass if the set is empty.  We're discussing ways to improve this in the future.

However, it is possible today to create a custom check-in policy that can apply any check-in criteria you'd like.  I think you could even do the exclusion you'd prefer with a different regular expression.  So, your regular expression to exlude all .java files would be an expression for "include all files that are not .java files".

I hope this helps.
Rick