[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Need help - tagging, branching, adding

From: Todd Denniston
Subject: Re: Need help - tagging, branching, adding
Date: Fri, 21 Sep 2007 13:03:48 -0500
User-agent: Thunderbird (X11/20070716)

Dennis Jones wrote, On 09/21/2007 12:05 PM:
"ferkee" <address@hidden> wrote in message news:address@hidden

Anyway, I would like to be able to (I guess) tag all the "Pre-Upgrade"
code as such for whatever reason (in case we need to revert back all
the files, for posterity's sake, etc.).

Easy *if* you have not made changes to the sources since giving them to the contractor. Assuming the sources for the contractor came out of CVS on the main trunk, then the easiest way is:

cvs rtag <tag> <module>

where: <tag> is the name you want to give the sources ("before-contractor-changes" for instance) and <module> is the name of your module (if you have one). If you are not using modules, then it is likely that you can use the top-level folder name ("proj" in your case). For example:

cvs rtag before-contractor-changes proj

However, without knowing more about the structure and state of your repository and sandbox, I cannot guarantee that this will do what you want.

THEN, I'd like to know how to
systematically put into CVS all the modified files, AND locate and add
any new directories and files.

That should be easy too. First make sure all of the files in your sandbox are up-to-date (in sync with the repository), and that you have a clean sandbox (no files that aren't already in the repository). Then, assuming your current sources are eactly the same as what the contractor started with, simply copy the sources from the contractor on top of your existing sources (except for any "CVS" administrative folders).

hard to tell from the email I got, but without knowing why there are CVS folders in the copy from the contractor, I would add the following: If the copy you got from the contractor has CVS administrative folders that are from YOUR CVS checkout, i.e., they did not use their own CVS repository while they modified the code, then instead of mucking about with copying, just run the commands in the contractor sandbox. If the sandbox from the contractor is from your repository, and you can't run the commands because of the contractor's user name being built into the administrative folders, it should be easier and safer to modify the "CVS" administrative folder files, than to copy things between sandboxes.

You probably don't really care which files were modified, *unless* you want to enter different commit messages for each file (or set of files), in which case you could use the command:

cvs -qn up

which will tell you which files were modified (indicated by an 'M' at the beginning of the line), and which files and folders are not in to the repository (indicated by a '?' at the beginning of the line). If you just want to know which files and folders are new (not in the repository, as opposed to modified files), you can use:

cvs -Qn up

Next, use CVS to add the new folders and files (those indicated by the '?') and commit everything. Finally, tag everything again:

cvs rtag after-contractor-changes proj

Remember, all of this is based on the following assumptions:

1) the original source code that you gave to the contractor exactly matched the repository at that time; 2) no changes occurred to the source code from the time you gave the code to the contractor to the time you got it back;
3) you are not using modules;
4) the source code did not come from a branch; (if it did, then a branch name is needed on the 'rtag' command)


- Dennis

Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

reply via email to

[Prev in Thread] Current Thread [Next in Thread]