How To: Edit a File Checked Out to Another User

I'm amazed by how often I see this question on the newsgroups and listservers.

faQ: How can I edit a file that another user has checked out?

A: Allow Multiple Checkouts
Iin VSS Administrator: Tools|Options|General|"Allow Mulitiple Checkouts".  The help topic for this option says, "Controls whether many people can check out one file simultaneously. Under ordinary circumstances, only one person can have a file checked out of VSS at one time. If you select this box, however, VSS allows many people to check out the same file. When the first user checks in the file, VSS updates the file; thereafter, VSS merges in all subsequent changes."

For concurrent software development--and especially in Extreme Programming shops--changing this option to TRUE can be quite helpful.

CAUTION: If your team uses VSS to store primarily binary, non-text files (doc, .xls, .dwg, etc), I do not recommend changing this option.  VSS can automatically merge differing versions of text files but cannot do so for binary files.

What do you think? 
Should "Allow Multiple Checkouts" be ON by default? If your team works in multiple checkout mode, how long did it take you to find the feature and how often do merge conflicts occur?

++++++++++++++++++++++++++++++++++++++++++++++++++++

This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft kann für die Richtigkeit und Vollständigkeit der Inhalte in dieser Newsgroup keine Haftung übernehmen. Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.

Published 12 September 03 02:56 by KorbyP

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Kevin Greiner said on September 12, 2003 3:14 PM:
No, it shouldn't be on by default. Where I work now, this is commonly known as the "CVS style" and is ridiculed becase these guys (most of them from an AS/400 background) highly value deterministic locking. They just can't understand how a team of developers could use this feature without it driving them nuts when merging.
# Mike Dimmick said on September 17, 2003 8:02 AM:
Unless your automatic merge is _very_ good, one developer at a time should be the default. It's easier to understand. The issues basically arise whenever you've got two (or more) developers that need to make a change to a single module. In the 'ownership' scheme, you essentially have to organise which developer is currently entitled to work on that module. You can run this in one of two ways: either one developer owns the module and makes all changes in it, or the developer that requires the change makes the change. In the first scheme, you then have to schedule developer A to make the change, which causes developer B to either have to wait, or to work on something else in the meantime. In the second scheme, assume that developer C has the module checked out. Developer A still needs to coordinate with developer C to get C to check in, allow A to make his changes, then allow C to check out the modified module to continue with his work. In the get/update/merge scenario, A can get the latest version that C has checked in (assuming, of course, that it compiles...), make his changes, and update the repository. When C then wants to save his current changes, the tool merges the changes, hopefully leaving us with a file that compiles correctly and contains both C and A's changes. However, merge tools aren't perfect by any stretch of the imagination, so C may have to complete the merge operation manually, incorporating both his own changes and A's. This might well require both developers to resolve, again requiring C and A to schedule themselves. (Aside: this is sounding very much like thread synchronisation!) My own view is that the only way round is to plan your project and tasks carefully, so that developers are, as far as possible, working on different areas of the code, and common modules are planned thoroughly to ensure that edits aren't required that often. So far in my career I haven't had to do much parallel development - I mostly work on projects that only require one developer at a time.
# RichB said on February 25, 2004 11:20 PM:
Yes, multiple checkout should be the default.

I use Perforce and subversion - both have multiple checkout. Microsoft use Perforce internally (SourceDepot) for large projects (think Windows). I always turn VSS multiple checkout on (except when prevented from doing so by the project manager because they have a mental block on how useful it would be).

If you only have 2 or 3 developers on a project and they never leave the same room - the default VSS behavior is workable. Whenever anyone works offsite or the team grows you forever have to pause your mental state to wait for another team member to check in.
# Kadar said on September 5, 2006 1:12 AM:
I understand that multiple checkouts should be by default. The only concern is how to handle conflict? This comes a manualy work all together as the second user or any user after the first check in needs to face merge, where in if there is a conflict how the user will tackle it?
# Kadar said on September 5, 2006 1:12 AM:
I understand that multiple checkouts should be by default. The only concern is how to handle conflict? This comes a manualy work all together as the second user or any user after the first check in or commit needs to face merge, where in if there is a conflict how the user will tackle it?
# Kadar said on September 5, 2006 1:12 AM:
I understand that multiple checkouts should be by default. The only concern is how to handle conflict? This comes a manualy work all together as the second user or any user after the first check in or commit needs to face merge, where in if there is a conflict how the user will tackle it?
# Kadar said on September 5, 2006 1:12 AM:
I understand that multiple checkouts should be by default. The only concern is how to handle conflict? This comes a manualy work all together as the second user or any user after the first check in or commit needs to face merge, where in if there is a conflict how the user will tackle it?

Leave a Comment

(required) 
(optional)
(required) 

Search

Go

This Blog

Syndication

Page view tracker