head	1.3;
access;
symbols
	dlr:1.1.1
	TIGRIS_0_9_2_4:1.1
	TIGRIS_0_9_2_3:1.1
	HELM_PEER_PORT_BRANCH:1.1.1.1
	TURBINE_PEER:1.1
	TIGRIS_0_9_2_1:1.1
	TIGRIS_0_9_2:1.1.0.6
	TIGRIS_0_8_4:1.1.0.4
	TIGRIS_0_9_0:1.1.0.2;
locks; strict;
comment	@# @;


1.3
date	2001.02.26.23.37.47;	author lori;	state dead;
branches;
next	1.2;

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

1.1
date	2000.12.30.23.22.00;	author jrobbins;	state Exp;
branches
	1.1.1.1
	1.1.4.1
	1.1.8.1;
next	;

1.1.1.1
date	2001.02.21.00.31.52;	author dlr;	state Exp;
branches;
next	;

1.1.4.1
date	2001.01.16.00.17.44;	author susank;	state Exp;
branches;
next	;

1.1.8.1
date	2001.02.17.18.39.15;	author edk;	state Exp;
branches;
next	;


desc
@@


1.3
log
@removed file; obsoleted by 1.0 help
@
text
@<HTML>
<HEAD>

<TITLE>Version Control Primer</TITLE>

</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)
    </TD>
  </TR>
</TABLE>
</BODY>
</HTML>
@


1.2
log
@added <title> tags to all files
@
text
@@


1.1
log
@moved core documentation into helm, fewer overrides need to be in instances now
@
text
@d1 7
d99 2
@


1.1.1.1
log
@Replacing the HEAD with the HELM_PEER_PORT_BRANCH.
@
text
@a0 7
<HTML>
<HEAD>

<TITLE>Version Control Primer</TITLE>

</HEAD>
<BODY>
a91 2
</BODY>
</HTML>
@


1.1.8.1
log
@porting changes from the head to the branch
@
text
@a0 7
<HTML>
<HEAD>

<TITLE>Version Control Primer</TITLE>

</HEAD>
<BODY>
a91 2
</BODY>
</HTML>
@


1.1.4.1
log
@adding the generic, default docs into this branch, bc they are in the head and nec for instantiations using stable branches
@
text
@@

