Lock level of file superceded by check out
When check out operation is performed on file, the lock set will be that of the check out option specified. It may lead to some not entirely obvious consequences.
Obvious example
1) No lock on file prior to check out
2) After check out is performed with lock option other than "None"("Check-out" or "Check-in" lock), the file is editable and has changes "Lock,Edit" associated with it (in "View Pending Changes" window)
Not so obvious example
1) Lock the file prior to check out ("Check-out" or "Check-in" lock)
2) After check out is performed with "None" lock option, the file is editable and has change "Edit" (in "View Pending Changes" window)
That is, lock was essentially removed by using check-out option!
So lock level may be either promoted or demoted by check out operation. Thus one may inadvertently change the lock level on file (very easy to do when file is locked and file is automatically checked out on contents edit).
In my opinion, the behavior is not exactly right. Lock promotion by check out is logical, but demotion appears to be overlooked in implementation.
Could anyone (preferrably MS) share thoughts on the subject?
WBR, Curedone
As far as the checkout dialog goes, we tried to make it clear that the lock choice is explicit and "trumps" any current lock state, in either direction. I suppose we could have had a 4th option "preserve" that would leave the current lock state intact.
If you're having a lock go away during an automatic checkout, that's a bug (at least, I think it is). Have you seen this happen?
The lock does go away. Check the scenario:
1) Lock file for check out. In "Pending Changes" window Change displayed is "Lock"
2) Perform check out setting lock mode to none. The file is checked out and in "Pending Changes" window Change displayed is "Edit"
So if user does not perform check out explicitly but by editing file, and automatic check out on edit is enabled, lock just quietly goes away.
In my opinion, if user spaces 1 and 2 in time, he will probably wont pay any attention that lock disabled (as also the icon in solution explorer wont change).
I must be missing something. Your step #2 is an explicit checkout, not an automatic one. And as I said, you made an explicit choice to select "none" for the lock, rather than check-in or check-out.
If there's ever a scenario where an *automatic* checkout fails to preserve an existing lock, that's a bug. The common example would be where you start editing a file in a versioned solution which you had previously locked (but not checked out).
Well, I included that for illustration purposes only. If you do an "automatic" check out it results in the same behavior. I suggest you try that out.
I think the issue here is not that lock is not enforced for the same user (which is all right); the problem is that the user may inadvertently lose the lock.
Let me know if I made myself clear - overwordlines seems to be a failure of mine :-)
Adam Singer, the test owner for the lock feature, is investigating the automatic-checkout scenario.
I'm unable to reproduce with with our RTM bits using the automatic checkout on edit feature. To turn on automatic check out, go to "Tools" -> "Options..." -> "Source Control" -> "Environment" and make sure the "Editing" drop down is set to "Check out automatically". Here are my repro steps:
- File -> New Project; select a C# console application
- Right-click on the solution and Add to source control
- Check in the solution
- In Source Control Explorer, navigate to Program.cs and lock it with a checkout lock
- In Solution Explorer, double-click on Program.cs
- Start typing text in the Program.cs file
- After checkout completes, check the status of Program.cs both from Source Control Explorer and from the command line- it has a pended edit and a lock
If you explicitly check out a file from the Source Control Explorer, you must choose which lock type you want to have on the files specified. Automatic check out, however, does not seem to affect locks. Do you have a repro case in which it does unlock the file?
Hope this helps-
Cheers,
Adam
Thank you very much Adam for your timely reply.
I have double-checked (should have done that from the very beginning), and you indeed in the right. You can change the lock status only when doing explicit check out; when automatic checkout is performed, lock stays as is. My sloppiness in refreshing the "Pending Changes" window I think...
However, I am somewhat intrigued at how locking works. Ok, for explicit check out the lock option specified supercedes the lock set (and that it is so by design).
But what happens with automatic check out? Is automatic check out by file edit always leaves lock as is? And what happens if concurrent check out is disabled for the project?
Would be very obliged for any insights into inner workings of locks.
Again, thanks a lot for your time.
Yours truly.
Most pending change commands have a Lock parameter in the OM ('/lock:<foo>' on the command line). It's mostly a convenience/optimization so you don't have to make another server call to the lock & unlock commands separately. You can only use these to manipulate locks that you own, unless you have the UnlockOther permission (usually only given to admins).
With automatic checkout, the client does not pass any lock options to the server, so the lock state is preserved.
If concurrent checkout is disabled for the team project, then the server will add a "check-out" (exclusive) lock to all pending changes regardless of what the client specifies. So automatic checkouts -- as well as renames, branches, deletes, etc., which don't have their lock parameter exposed in the UI -- all result in locks. To avoid confusion, if you try an explicit checkout, the bottom half of the dialog (where you'd ordinarily choose lock type) is greyed out. If you try to unlock a file from the command line or Source Control Explorer, the server will generate an error message -- the only way to unlock is to Undo.
Files with extensions listed as non-mergeable (Team -> TFS Settings -> SC File Types) work exactly the same as disabling concurrent checkout for those files.
