Cvs and updating to head
To get rid of files, use cvs delete: CVS uses a "lazy" system for file deletion; delete just changes the way that the file is stored in the repository.It's still possible to undelete the file, or to check out revisions that existed before the file was deleted.The "Merging adds and removals" node of the info pages contains an example that is nearly identical to what I was trying to do and is close to what I actually tried.Here is that example for a quick reference: cvs update -A touch a b c cvs add a b c ; cvs ci -m "added" a b c cvs tag -b branchtag cvs update -r branchtag touch d ; cvs add d rm a ; cvs rm a cvs ci -m "added d, removed a" cvs update -A cvs update -jbranchtag The cvs info pages further says that: After these commands are executed and a `cvs commit' is done, file `a' will be removed and file `d' added in the main branch.All documents are contained in a central CVS repository, located on the slac.network node.There is a CVS server application which runs on the central repository node and communicates with the various CVS client applications used by the individual users.
Here the CVS client will compare the file in the users working directory to the copy that exists on the server, log any differences, and copy the users copy of a file to the repository.Private tags cannot be submitted for release builds, an "official" tag will have to be made at that point.It is preferred that all tags be either of the "official" form or the "private" form, and not a mix of the two.A quick way to open all the files that have conflicts (in Vim): don't matter, as long as they make sense (for what the branch does) and match.If you're working on a branch, inevitably someone else checks in a change on the head (or merges another branch) adding functionality you want, or substantially changing code that you are about to (or have already) change.One needs to compare files if the label is 'M' or 'C'. If there is differences that do not belong to you, consider option 2) and 3). These usually consist of the users initials plus the date, e.g.Use 'cvs diff -Dnow' to compare local version with the HEAD. th030212 (or th030212a if more than one is made per day).The difference between the above and what I did was that instead of using cvs update -A in the second to last step I used cvs update -r HEAD (too bad I tried working from memory instead of reviewing the info pages again before doing this...doh) Here's the detailed list of what I did: I created a branch off the main development (i.e. I made a bunch of changes on the new branch and then wanted to merge these all back to cvs HEAD.So I went to my sandbox (which was currently on branch-2 with all changes commited) and ran the following: # Move sandbox back to CVS HEAD cvs update -r HEAD # I believe I should have used 'cvs update -A' # Merge in the differences between HEAD and branch-2 cvs update -j branch-2 # Try to commit the changes cvs commit -m "Merged changes from branch-2" At that point, I got a lot of errors saying that I had a sticky tag on my files. It worked on all files which existed on HEAD before the merge from branch-2.$ cvs status driver.c =================================================================== File: driver.c Status: Up-to-date Version: 220.127.116.11 Sat Dec 5 1992 rcs Version: 18.104.22.168 /u/cvsroot/yoyodyne/tc/driver.c,v Sticky Tag: rel-1-0-patches (branch: 1.7.2) Sticky Date: (none) Sticky Options: (none) option retrieves the version of the file from the head of the trunk, and forgets any sticky tags, dates, or options.The most common use of sticky tags is to identify which branch one is working on, as described in the section called “Accessing branches”. For example, suppose that you want to avoid updating your working directory, to isolate yourself from possibly destabilizing changes other people are making.