head	1.5;
access;
symbols
	TIGRIS_1_1_0RC2:1.2.6.1
	TIGRIS_1_1_0RC1:1.2.6.1
	TIGRIS_1_1:1.2.6.1.0.2
	TIGRIS_1_0_8:1.2
	TIGRIS_1_0_8RC3:1.2
	TIGRIS_1_0_8RC2:1.2
	TIGRIS_1_0_8RC1:1.2
	TIGRIS_1_0_7:1.2
	TIGRIS_1_0_7RC3:1.2
	TIGRIS_1_0_7RC2:1.2
	TIGRIS_1_0_7RC1:1.2
	TIGRIS_1_0_6:1.2
	TIGRIS_1_0_6RC5:1.2
	TIGRIS_1_0_6RC4:1.2
	TIGRIS_1_0_6RC3:1.2
	TIGRIS_1_0_6RC2:1.2
	TIGRIS_1_0_6RC1:1.2
	TIGRIS_1_0_5:1.2
	TIGRIS_1_0_5RC6:1.2
	TIGRIS_1_0_5RC5:1.2
	TIGRIS_1_0_5RC4:1.2
	TIGRIS_1_0_5RC3:1.2
	TIGRIS_1_0_5RC2:1.2
	TIGRIS_1_0_5RC1:1.2
	TIGRIS_1_0_4:1.2
	TIGRIS_1_0_3:1.2
	TIGRIS_1_0_2:1.2
	TIGRIS_1_0_1:1.2
	TIGRIS_1_0:1.2.0.6
	TIGRIS_1_0_0:1.2
	TIGRIS_1_0_0_RC1:1.2.0.2;
locks; strict;
comment	@# @;


1.5
date	2001.07.31.18.47.59;	author csjank;	state Exp;
branches;
next	1.4;

1.4
date	2001.06.21.07.07.40;	author jefflove;	state Exp;
branches;
next	1.3;

1.3
date	2001.06.11.03.14.33;	author jefflove;	state Exp;
branches;
next	1.2;

1.2
date	2001.02.11.18.29.47;	author jrobbins;	state Exp;
branches
	1.2.6.1;
next	1.1;

1.1
date	2001.01.29.19.44.19;	author lori;	state Exp;
branches;
next	;

1.2.6.1
date	2001.07.31.19.37.05;	author csjank;	state Exp;
branches;
next	;


desc
@@


1.5
log
@removed reference to Help.html (file no longer exists)
@
text
@  <div class="docs" id="ddcvscvsprimer">
   <h2>A version control primer</h2>

   <p>A version control system maintains an organized set of all the versions of files that are made over time. Version control systems allow people to go back to previous versions, and to compare any two versions to see what changes were made between them. In this way, version control keeps a historically accurate (and retrievable!) log of a file's evolution. More importantly, version control systems help several people (even in geographically disparate locations) work together on a development project over the Internet or private network to make changes to the same file over time.</p>

   <h3>Key concepts in version control:</h3>

   <dl>
    <dt>Repository:</dt>

    <dd>a shared database the the complete version history of all files under version control.</dd>

    <dt>Workspace:</dt>

    <dd>a copy of the files you want to edit on your local hard disk or Unix user account. When you edit files in your workspace, they will become out of sync with the repository. That's progress! Then you need to get your changes back into the repository so that everyone else can see them.</dd>

    <dt>Checking out a file or directory:</dt>

    <dd>this copies a version (usually the latest version) of a file from the repository to your workspace. When you check out a directory, you check out all files and subdirectories under it.</dd>

    <dt>Checking in a file or directory:</dt>

    <dd>this copies your working directory back into the repository as a new version.</dd>

    <dt>Committing a file or directory:</dt>

    <dd>is the same as checking it in. Often version control users will say that the have "committed a change"; this means that they made changes and committed these back to the repository.</dd>

    <dt>Version:</dt>

    <dd>a numbered draft of a file, e.g., 1.1, 1.2, 1.3, 1.4, 2.0, 2.1. Each time you edit a file and commit it back to the repository, its version number increases. You can change the first digit of the number any time you like.</dd>

    <dt>Conflict:</dt>

    <dd>When two people make changes to the same file at the same time, their work may conflict. There are two ways to address conflicts: locks and merging.</dd>

    <dt>Locks:</dt>

    <dd>one strategy for managing conflicts in version control is to lock files so that only one person can check out a read-write copy at a time. Other users can only get read-only copies. This prevents two people from ever working on the same file at the same time. It is safe, but not very efficient in practice. Also, if one person locks a file and then leaves for the day or the week, no one else can work with that file, so they are needlessly blocked.</dd>

    <dt>Merging:</dt>

    <dd>another strategy for managing conflict is to let multiple people work at the same time (with no locks) and then try to merge their results into one combined version. This is closer to the way that intelligent people tend to work together in parallel if they had no version control tools. Merging works well when two sets of changes can be combined, and poorly when it is impossible to combine changes. CVS uses merging.</dd>
   </dl>

   <p>More information: <a href="http://www.cvshome.org/new_users.html">CVS for New Users</a> (an article)</p>

   <div class="courtesylinks">
    <p><a href="/servlets/HelpTOC">Back to main Help index</a></p>
   </div>
  </div>
 


@


1.4
log
@html usage revision
@
text
@d49 1
a49 1
    <p><a href="Help.html">Back to main Help index</a></p>
@


1.3
log
@extensive markup rework - first pass toward house xhtmlification
@
text
@d1 2
a2 6
<!DOCTYPE html PUBLIC "-//CollabNet//DTD XHTML 1.0 Transitional//EN"
"http://collabnet.com/dtds/collabnet_transitional_10.dtd">
<html>
 <head>
  <title>Version Control Primer</title>
 </head>
d4 1
a4 3
 <body>
  <div class="docs" id="docid">
<h2>A version control primer</h2>
d6 1
a6 1
  <p>A version control system maintains an organized set of all the versions of files that are made over time. Version control systems allow people to go back to previous versions, and to compare any two versions to see what changes were made between them. In this way, version control keeps a historically accurate (and retrievable!) log of a file's evolution. More importantly, version control systems help several people (even in geographically disparate locations) work together on a development project over the Internet or private network to make changes to the same file over time.</p>
d8 2
a9 1
  <h3>Key concepts in version control:</h3>
d11 1
a11 2
  <dl>
   <dt><strong>Repository</strong>:</dt>
d13 1
a13 1
   <dd>a shared database the the complete version history of all files under version control.</dd>
d15 1
a15 1
   <dt><strong>Workspace</strong>:</dt>
d17 1
a17 1
   <dd>a copy of the files you want to edit on your local hard disk or Unix user account. When you edit files in your workspace, they will become out of sync with the repository. That's progress! Then you need to get your changes back into the repository so that everyone else can see them.</dd>
d19 1
a19 1
   <dt><strong>Checking out a file or directory</strong>:</dt>
d21 1
a21 1
   <dd>this copies a version (usually the latest version) of a file from the repository to your workspace. When you check out a directory, you check out all files and subdirectories under it.</dd>
d23 1
a23 1
   <dt><strong>Checking in a file or directory</strong>:</dt>
d25 1
a25 1
   <dd>this copies your working directory back into the repository as a new version.</dd>
d27 1
a27 1
   <dt><strong>Committing a file or directory</strong>:</dt>
d29 1
a29 1
   <dd>is the same as checking it in. Often version control users will say that the have "committed a change"; this means that they made changes and committed these back to the repository.</dd>
d31 1
a31 1
   <dt><strong>Version</strong>:</dt>
d33 1
a33 1
   <dd>a numbered draft of a file, e.g., 1.1, 1.2, 1.3, 1.4, 2.0, 2.1. Each time you edit a file and commit it back to the repository, its version number increases. You can change the first digit of the number any time you like.</dd>
d35 1
a35 1
   <dt><strong>Conflict</strong>:</dt>
d37 1
a37 1
   <dd>When two people make changes to the same file at the same time, their work may conflict. There are two ways to address conflicts: locks and merging.</dd>
d39 1
a39 1
   <dt><strong>Locks</strong>:</dt>
d41 1
a41 1
   <dd>one strategy for managing conflicts in version control is to lock files so that only one person can check out a read-write copy at a time. Other users can only get read-only copies. This prevents two people from ever working on the same file at the same time. It is safe, but not very efficient in practice. Also, if one person locks a file and then leaves for the day or the week, no one else can work with that file, so they are needlessly blocked.</dd>
d43 2
a44 1
   <dt><strong>Merging</strong>:</dt>
d46 1
a46 2
   <dd>another strategy for managing conflict is to let multiple people work at the same time (with no locks) and then try to merge their results into one combined version. This is closer to the way that intelligent people tend to work together in parallel if they had no version control tools. Merging works well when two sets of changes can be combined, and poorly when it is impossible to combine changes. CVS uses merging.</dd>
  </dl>
d48 3
a50 4
  <p>More information: <a href="http://www.cvshome.org/new_users.html">CVS for New Users</a> (an article)</p>

  <div class="courtesylinks">
   <a href="Help.html">Back to main Help index</a>
d52 1
a52 3
 </div>
</body>
</html>
@


1.2
log
@added <title> tags to all files
@
text
@d1 61
a61 2
<HTML>
<HEAD>
a62 1
<TITLE>Version Control Primer</TITLE>
a63 99
</HEAD>
<BODY>
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
    <TD class="Header" nowrap>A version control primer</TD>  
  </TR>
</TABLE>

<TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" BORDER="0" width="100%">
  <TR>
    <TD class=PlainText>
     <P>A version control system maintains an organized set of all the
     versions of files that are made over time. Version control
     systems allow people to go back to previous versions, and to
     compare any two versions to see what changes were made between
     them. In this way, version control keeps a historically accurate
     (and retrievable!) log of a file's evolution. More importantly,
     version control systems help several people (even in
     geographically disparate locations) work together on a
     development project over the Internet or private network to make
     changes to the same file over time.

     <P><span class="InputHeader">Key concepts in version control:</span>
     <DL>
      <DT><span class="PlainTextBold">Repository</span>: 
      <DD>a shared database the the complete version history of all
      files under version control.

     <P>
      <DT><span class="PlainTextBold">Workspace</span>: 
      <DD>a copy of the files you want to edit on your local hard disk
      or Unix user account. When you edit files in your workspace,
      they will become out of sync with the repository. That's
      progress!  Then you need to get your changes back into the
      repository so that everyone else can see them.

     <P>
      <DT><span class="PlainTextBold">Checking out a file or directory</span>: 
      <DD>this copies a version (usually the latest version) of a file
      from the repository to your workspace. When you check out a
      directory, you check out all files and subdirectories under it.

     <P>
      <DT><span class="PlainTextBold">Checking in a file or directory</span>: 
      <DD>this copies your working directory back into the repository
      as a new version.

     <P>
      <DT><span class="PlainTextBold">Committing a file or directory</span>: 
      <DD>is the same as checking it in. Often version control users
      will say that the have "committed a change"; this means that
      they made changes and committed these back to the repository.

     <P>
      <DT><span class="PlainTextBold">Version</span>: 
      <DD>a numbered draft of a file, e.g., 1.1, 1.2, 1.3, 1.4, 2.0,
      2.1. Each time you edit a file and commit it back to the
      repository, its version number increases. You can change the
      first digit of the number any time you like.

     <P>
      <DT><span class="PlainTextBold">Conflict</span>: 
      <DD>When two people make changes to the same file at the same
      time, their work may conflict. There are two ways to address
      conflicts: locks and merging.

     <P>
      <DT><span class="PlainTextBold">Locks</span>: 
     <DD>one strategy for managing conflicts in version control is to
     lock files so that only one person can check out a read-write
     copy at a time. Other users can only get read-only copies. This
     prevents two people from ever working on the same file at the
     same time. It is safe, but not very efficient in practice. Also,
     if one person locks a file and then leaves for the day or the
     week, no one else can work with that file, so they are needlessly
     blocked. 

    <P> <DT><span class="PlainTextBold">Merging</span>:
      <DD>another strategy for managing conflict is to let multiple
      people work at the same time (with no locks) and then try to
      merge their results into one combined version. This is closer to
      the way that intelligent people tend to work together in
      parallel if they had no version control tools. Merging works
      well when two sets of changes can be combined, and poorly when
      it is impossible to combine changes. CVS uses merging.
     </DL>

     <P>More information: <A
     HREF="http://www.cvshome.org/new_users.html">CVS for New
     Users</A> (an article)

<HR noShade SIZE=1>
<a href="Help.html">Back to main Help index</a></p></span>

    </TD>
  </TR>
</TABLE>
</BODY>
</HTML>
@


1.2.6.1
log
@fixed broken links
Issue number:
Obtained from:
Submitted by:
Reviewed by:
@
text
@d98 3
a100 1
    <a href="/servlets/HelpTOC">Back to main Help index</a></p></span> </TD>
@


1.1
log
@new and revised help documentation for v1.0
@
text
@d1 7
d103 2
@

