Compartilhar via

How To: Edit a File Checked Out to Another User

  • Artigo

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.

Comments

  • Anonymous
    September 12, 2003
    The comment has been removed
  • Anonymous
    September 17, 2003
    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.
  • Anonymous
    February 25, 2004
    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.
  • Anonymous
    September 04, 2006
    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?
  • Anonymous
    September 04, 2006
    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?
  • Anonymous
    September 04, 2006
    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?
  • Anonymous
    September 04, 2006
    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?