Source Control: Difference between revisions

From VrlWiki
Jump to navigation Jump to search
mNo edit summary
Jadrian Miles (talk | contribs)
mNo edit summary
Line 5: Line 5:
Ordinarily, the first steps of development for your own software project happens somewhere in your homedir.  This doesn't allow other people to work with your code, though, so once your project is nontrivial you should add it to <code>$G</code> using the <code>gfxprojinit</code> script.  This script creates a home for your project in <code>$G/src</code>, but not everything associated with a given project belongs there.  To get everything into the right place, follow these steps:
Ordinarily, the first steps of development for your own software project happens somewhere in your homedir.  This doesn't allow other people to work with your code, though, so once your project is nontrivial you should add it to <code>$G</code> using the <code>gfxprojinit</code> script.  This script creates a home for your project in <code>$G/src</code>, but not everything associated with a given project belongs there.  To get everything into the right place, follow these steps:
# Go to the directory that has your source in it.
# Go to the directory that has your source in it.
# Delete or move away anything you don't want to go into CVS.  If you already have something compiled, do <code>make clean</code> to get rid of the object files&mdash;you don't want to put them in CVS. In general, just leave the Makefile and the source files.
# Delete or move away anything you don't want to go into CVS.  If you already have something compiled, do <code>make clean</code> to get rid of the object files --- you don't want to put them in CVS. In general, just leave the Makefile and the source files.
#* '''Note:''' even though non-source files are sometimes necessary for builds of complex projects, data and config files don't belong in <code>$G/src</code>!  Carefully consider whether non-source files belong in the <code>$G/src</code>; they most likely do not and belong in <code>$G/lib</code> (or <code>$G/data</code> for example data on which your program runs) instead.  Move these out of the directory temporarily; we'll check them into the appropriate locations later.
#* '''Note:''' even though non-source files are sometimes necessary for builds of complex projects, data and config files don't belong in <code>$G/src</code>!  Carefully consider whether non-source files belong in the <code>$G/src</code>; they most likely do not and belong in <code>$G/lib</code> (or <code>$G/data</code> for example data on which your program runs) instead.  Move these out of the directory temporarily; we'll check them into the appropriate locations later.
# If you have any binary files, like images, that you want to go in CVS, move them out of this directory temporarily.  We will add them later because CVS requires non-text files to be added with a special flag.  Once again, keep in mind that most binary files are program resources and belong in <code>$G/lib</code>  rather than <code>$G/src</code>.
# If you have any binary files, like images, that you want to go in CVS, move them out of this directory temporarily.  We will add them later because CVS requires non-text files to be added with a special flag.  Once again, keep in mind that most binary files are program resources and belong in <code>$G/lib</code>  rather than <code>$G/src</code>.
# Run the following command, replacing &lt;projectname&gt; with the name you want your project to have&mdash;that will become a new directory under <code>$G/src</code>: <pre>gfxprojinit &lt;projectname&gt; .</pre>
# Run the following command, replacing &lt;projectname&gt; with the name you want your project to have --- that will become a new directory under <code>$G/src</code>: <pre>gfxprojinit &lt;projectname&gt; .</pre>
#* Note the period at the end of that command.  It might be hard to see, but it is important.
#* Note the period at the end of that command.  It might be hard to see, but it is important.
#* It's worth knowing, for those familiar with CVS, that <code>gfxprojinit</code> is essentially a fancy wrapper around <code>cvs import</code>.  Please be sure to use <code>gfxprojinit</code> anyway, as it maintains important metadata and may do even more in the future.
#* It's worth knowing, for those familiar with CVS, that <code>gfxprojinit</code> is essentially a fancy wrapper around <code>cvs import</code>.  Please be sure to use <code>gfxprojinit</code> anyway, as it maintains important metadata and may do even more in the future.

Revision as of 22:27, 12 January 2009

This page describes how the bulk of existing code in $G is organized. Active projects are being migrated to a new directory structure using a common set of make files. Until the procedures are in place have Brad help you set up any new project. Students actively working on projects can also begin to migrate to the new directory structure.

The $G tree is not intended for users to write to directly, and future IT plans for our group include enforcing this restriction. Instead, we use the revision control system CVS as an interface to the directory structure in $G. CVS keeps track of changes to every file, allows concurrent editing of source code by multiple people, and provides an easy means for copying source trees to new locations.

Ordinarily, the first steps of development for your own software project happens somewhere in your homedir. This doesn't allow other people to work with your code, though, so once your project is nontrivial you should add it to $G using the gfxprojinit script. This script creates a home for your project in $G/src, but not everything associated with a given project belongs there. To get everything into the right place, follow these steps:

  1. Go to the directory that has your source in it.
  2. Delete or move away anything you don't want to go into CVS. If you already have something compiled, do make clean to get rid of the object files --- you don't want to put them in CVS. In general, just leave the Makefile and the source files.
    • Note: even though non-source files are sometimes necessary for builds of complex projects, data and config files don't belong in $G/src! Carefully consider whether non-source files belong in the $G/src; they most likely do not and belong in $G/lib (or $G/data for example data on which your program runs) instead. Move these out of the directory temporarily; we'll check them into the appropriate locations later.
  3. If you have any binary files, like images, that you want to go in CVS, move them out of this directory temporarily. We will add them later because CVS requires non-text files to be added with a special flag. Once again, keep in mind that most binary files are program resources and belong in $G/lib rather than $G/src.
  4. Run the following command, replacing <projectname> with the name you want your project to have --- that will become a new directory under $G/src:
    gfxprojinit <projectname> .
    • Note the period at the end of that command. It might be hard to see, but it is important.
    • It's worth knowing, for those familiar with CVS, that gfxprojinit is essentially a fancy wrapper around cvs import. Please be sure to use gfxprojinit anyway, as it maintains important metadata and may do even more in the future.
  5. If you had some extra files you wanted to add to CVS, like build components, config files, program resources, or example data, you now want to check them into the relevant directories, which will be among $G/src/<projectname>, $G/lib/<projectname>, and $G/doc/<projectname>. For each relevant directory, which we'll call $X, do the following:
    1. Create $X, import it into CVS, then delete it and check it back out.
    2. Copy each appropriate file into $X, and for each one run the command:
      cvs add -kb <filename>
    3. After adding all the files, run:
      cvs commit -m "<commit message>"
  6. Your project should have been automatically added to the $G/src directory on the filesystem you are on now. To get it in the $G/src directory somewhere else, like at the Cave, run this command from within $G/src:
    cvs update -d <projectname>
    You may also need to use the same command in $G/lib and $G/doc.