|
Civilution Tools for evolving civilizations |
  | ||
  |   |
CVS for Civilution membersOK, I'm going to regurgitate what little I know about CVS that is most relevant to everyone.
In MOST (non-web) development situations, CVS works by keeping one "master" copy, then doling out "slave" copies to
the personal workspaces of developers that ask for them. if two developers both checkout and edit the same file, the
last person to BUT we are all working in the same directory. If two (or more) of us try to edit the same file at the same time, we are going to run into emacs and vi file locks. Those are far more annoying than CVS, so I suggest we deal with this problem by not editing the same file at the same time. If you have a strong reason to edit the same file at the same time as another developer here, either our file architecture is waay lame or you should be pair programming (or somebody locked the file by changing something in an open editor and left on a 3-day weekend).
All files in
PROCEDURAL RECOMMENDATIONS:
StatusSince all files are always checked out, you don't need to do anything special when you want to edit a file in the first place. But there is one thing you should do:
To see if a given file (say,
The status of a file that HAS NOT been modified is
Difference
If no one present admits to altering the file, you may want to see just how different the current version is from the most recent CVS-endorsed version. Use the following (the only line you have to type is the first one):
All the lines that start with a "<" are in the master copy, but have been deleted by whomever has modified the version you want to work on. All lines starting with ">" have been recently added. Notice that I also added a couple blank lines in the above example.
If the file has changed significantly since the last commit, you should commit the changes yourself (relax - I'm getting to
that part). Don't worry about the fact that you don't know what had just been changed, log the commit with something
like, "
More DifferenceTo see what has changed between two versions, neither of which is the latest, do something like:
CommitIn order to check in changes that have been made to a file and add a comment describing your changes to the CVS logs for that file, use:
The
If you want to add a long comment to describe your changes, you should set either the
Then either log out and in again or How frequently should we commit? I suggest we commit modifications whenever one of the following happens:
DeleteNothing ever really escapes from CVS. But if you want to think that it does, do the following:
This is reversible. Removing directories is a non-trivial operation. If you really want to do this, ask me and I'll try to learn how.
AddIf you found it necessary to create a new file in the first place, chances are you will want to have the same file in the same spot if you ever ask CVS to replicate the directory structure as it was at that moment in time.
Adding new directories is also very simple:
In order to add new files in a new directory, add the directory first, then cd directory and add the files.
Update and Log - Gleaning Information from CVS
-n part of the command tells CVS not to actually change anything, but to just tell you what it would change. Do
not forget the -n .
You can read more about the output of cvs update here or by typing man cvs. cvs log is how you view the comments entered during commits:
More about UpdateYou broke it. You don't know why, but the changes you have made to version 1.27 just won't cut it. Time to retreat to version 1.24:
Branching
At present, the files in
sextant-1-0a release into a new branch titled sextant-1-0a-staging . Now I could delete what was already in /web/sextant-staging and run:
sextant-dev after the instant I ran the cvs tag command (number
2 above) was included in the release sextant-1-0a-staging .So now, if we ever in the future need access to the contents of release sextant-1-0a exactly as they were when I first tagged the sources, we can
get them into a directory named sextant-NEW by running:
UN-Branching (Merging)Great. Now, instead of just having our development directory tree to worry about, we have added a branch, doubling the size of the tree (and of course complexity scales in a merely linear fashion with additional branches, right?). Since all four of us are on both the development team and the testing team at the same time, we are constantly encountering permutations of the following scenario: I just fixed this annoying bug inIf we were not all doing double-duty here, we testers would be content to play in our little universe of staging until the bugs were worked out. At that point, someone would magically merge our bug-fixes in staging back into the development sources. If we worked only in development, we likewise wouldn't care what went on in staging. But since we do both, everyone here needs to know how to merge changes so you don't drive me mad with requests of this nature. This is not a trivial operation. Scenario 1:
Notice that what you type in step 6 and 8 is dependent on what you get from step 3. What you are looking for is the most recent merge tag. It will look something like sextant-1-0a-staging-merge4 and will be at the top of the
heading titled "symbolic names:". This label will be followed by a
colon and a number - don't worry about that stuff, you only need to enter the label.Step 8 is where you set the next merge tag. Increment the tag you read in step 3. I.e.:
No, you aren't done yet. Well, maybe if you got lucky. If not, CVS detected a conflict on your attempted merge (if it
has, it will say, "
21 It demonstrated good behavior I suppose.
20 MORE changes. I need an example for the CVS help page.
Scenario 2:
Once again, you are looking for the most recent merge tag in step 4. If you do not run step 3, step 5 will skip files in sextant-dev which have been edited since their last commit (that would be bad). You should read through the list of all the scenarios cvs update may encounter so you know how to avoid them.
Do not fear, there are only 7.
Merging the other directionHow about if you make some change on the development server that you want to port over to the staging server?
YOU DON'TThe whole point of having staging is so we don't randomly incorporate additional features that may not be ready. Once ALL of the sources under development are approved as a unit by all of us, we tag another alpha version and roll it to staging en-masse. This really shouldn't happen more frequently than every week or two.
emacsMarkD@arsdigita.com wrote a short, simple summary of how to use emacs commands to accomplish CVS-related tasks.
More CVS. Must know more CVS!Here is a comprehensive CVS reference.The whole shebang is in just one file, which makes it very convenient to use your browser's text searching capability.
How to Annoy the CVS AdminIf you've read this far, it's probably clear to you that I have no love for CVS. Therefore, I am unlikely to appreciate any actions which require me to spend more time wrestling with arcane CVS commands. Or even with common CVS commands. In fact, if I never encounter another CVS command or reference as long as I live, I will get steadily happier and happier until I die of sheer unbridled ecstasy. To prevent this from happening, try one of the following:
Ignoring CVS
Fine, so what happens if all us Civiloonies ignore CVS completely while doing development? We can still
use CVS once we decide that So there really is no point to using CVS unless we conscientiously commit our edits with informative log entries.
deane@civilution.com |
  |