Re: Need help - tagging, branching, adding

[Todd Denniston]

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)
>
> HTH,
>
> - Dennis 


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