Mastering Visual Studio .NET 1002003 [Electronic resources] نسخه متنی

D.4 Checking In and Out

Once your solution is in source control,
you will not be allowed to modify it in any way without first
checking out items you wish to change. This is
to make sure that multiple developers don't work on
the same file at the same timea file can be checked out by
only one developer at a time.

You can check an item out by selecting it in the Solution Explorer
and then selecting File Source Control
Check Out Filename.
(The File menu will display the name of the selected file.)
Alternatively, you can right-click on the file in Solution Explorer
and select the Check Out... option from the context menu. Finally, if
you attempt to modify a file that is not checked out (e.g., by typing
in a source file or by changing a project's
settings), VS.NET will offer to check the file out for you. (Of
course, if some other developer has the file checked out, you will
not be allowed to check it out until he checks it back in.)

Whichever of the mechanisms you use for checking out a file (or
files, since you can check out multiple items at the same time), you
will be shown the Check Out dialog, which is shown in Figure D-4. The Comments section allows you to specify
the reason for checking the file outthis will be visible in
the VSS browser, so you can let other users know why you have locked
the file.

Figure D-4. Check Out dialog box

When this dialog appears as a result of attempting to edit a file that is not checked out, in place of the Cancel button you will find an Edit button. If you click Edit, VS.NET will allow you to modify the file without checking it out, although it will warn you that this is likely to lead to loss of data. This can sometimes be useful for performing an experimental change without having to check the file out. But be aware that such changes are transientthe source control database contains the master copy, and any changes made outside of source control are liable to be overwritten whenever you update your local copy of the project.

Once you have made the changes you require, you will want to push
those changes back to the source control databaseVS.NET always
edits local copies of files, and you need to tell it when to write
those copies back. This process is known as checking
in, and it is done in much the same way as checking
outselect the file or files in the Solution Explorer and
select Check In, either from the File Source
Control menu or from the Solution Explorer context menu.

D.4.1 Checking Out Versus Getting Latest Version

When you check out a file, VS.NET
makes sure that your local copy is the most up-to-date version. So if
the file has been changed by someone else recently, you may find that
it looks different after you check it outVS.NET has fetched a
new version to make sure you are starting from the right place.

Checking a file out is not the only way of retrieving the latest
version. If you right-click on a solution, project, or file in the
Solution Explorer, you will find a Get Latest Version option. (For
projects or solutions, this will usually have the text
"(recursive)" appended, which
indicates that it will retrieve the latest versions of everything in
the solution and project, as opposed to just the
.sln or project file.) This consults the source
control database to see if any of the files have been modified by
other developers, and if so, it copies the new versions to your
system.

In a group project, you should get the latest version of any files in
a solution you are working on regularly to make sure that your local
copy of the project doesn't drift too far from the
copy in the source control database. For the same reason, you should
also regularly check in any files that you have checked out.

D.4.2 Check In Frequently

As a general rule, you should check
in early and often. Automated builds typically work by retrieving the
most recent version of the project from source control and building
that. Changes you make to files will not be available in source
control until you check those changes in, so your code will not
become part of a nightly build until you check it in.

When multiple developers are involved, if files are not checked in
regularly, the local copies of the project on the various
developers' machines can become radically
differentdeveloper A may be writing code that works in
conjunction with some class that is in the process of being modified
by developer B. When they both eventually check their changes back
in, the project may fail to work. These integration niggles are
irritating, but in isolation they are usually fairly easy to fix.
However, if you leave it for days or even weeks between checking
files in, you are likely to have a huge integration mess to sort out
before anything will work. If all the developers make a habit of
trying not to go longer than a day or two between synchronizing their
local copies with the database, these problems don't
have the opportunity to grow.

Moreover, if you have a file checked out, nobody else can work with
it. If you keep files checked out for long periods of time, you may
end up holding other developers up. (Although if you really do have
to work on a particular file for an extended period, it is usually
best to check it in and back out every time you complete some
meaningful unit of work, just to make sure that the copy in the
source control database is kept up-to-date.)

Also, any sane development team will make sure that the server that
contains the source control database is backed up on a regular basis
(usually daily). However, it's not uncommon for
developer machines not to be backed up at all. So checking in
regularly reduces the potential for data loss.

For all these reasons, you should aim to keep as few files checked
out as possible and to check files in as soon as you can.