Some of it is purely historical, required for compatibility with RCS (upon which CVS was built), and hence serves no useful purpose. The major rev number (to the left of the first decimal) is an exam
I do a pre- and post network traversing md5sum against VIFs (Very Important Files) and maintain the outputted hashes for comparison. By this, I mean that I maintain a checkout on the repo box itself,
Hi all, (1) some more info: The project has about 20 tags and several branches. The current CVS version of the corrupt file is Revision 1.88. The CVS repository lies on a UNIX server the checkout pro
Forgot the subject before. Whoops. It turns out my test case was too simple, and this was a pathological case for the diff/patch step, because there wasn't any context. I'm still not sure why the tex
Sorry this is long, but i'm hoping this is an instructive example. I'm trying to take the delta between two revisions of a file on a branch and merge that delta onto the trunk. This doesn't seem to w
we handled this by forcing versions on the branches when we create them with the "cvs ci -F" command then we wrote a reserve script that gets the revision from the CVS/Entries file and locks it "admi
Appendix A-5 of the 1.12.12 version cederqvist says "HEAD refers to the most recent version available in the repository" when it describes "-r tag". This is the only place in cerderqvist that has a f
any No. That is not correct. Revision numbers are per file. a branch tag refers to a whole set of revisions on a set of files. Each file on the branch has a revision number which is completely indepe
It's still user error ;-) The branches were applied _before_ any modifications were made. The branch point is still the same: 1.6 You'll notice they do have different branch points - one is 1.6.4 an
[...] ?? RCP_5_0_2 looks like a revision off the RCP_5_0_2 branch to me. you have a branch also off of 1.103. Looking at it again now, I see that it's the same branch, RCP_5_0_1. RCP_5_0_2 is a revis
The attached patch is an experimental patch that adds commit naming, which allows CVS to assign a "name" to a commit. The name can later be used in the history or as a parameter to the patch command
No, the definition of being binary is that the usual text-file conversions should not be performed. It is possible to have mergeable binary files, although obviously the usual CVS merge won't work. A
I see the script has a few obvious errors. I've snipped the offending lines from the quote below. I snagged the script from my shell history, but didn't clean it up quite enough. <snip> I'd venture t
-- Forwarded mail from address@hidden (Greg Woods) Branches should never be used to separate files that should in actuality have different version histories. Using version-based attributes to determi
[ On Thursday, December 21, 2000 at 00:22:41 (-0600), David L. Martin wrote: ] First off, let's get one thing straight here. Merging of a binary file is, by definition, impossible. I.e. merging can *
As long as the rcsfile(5) specification is met, then all of RCS' features, warts, and concepts will follow. That specification also allows specifically for extensions to be introduced in particular
easy follow the magic vendor branch 1.1.1.x, T10 is probably the tag that represents the most recent vendor-branch import. now the 'T2 (revision: 1.1.1.2)' and 'T2 (revision: 1.1.1.1)' looks funny, d
English is subtle and it is perhaps possible that better wording could be arranged. You will never be able to commit to a specific revision that already exists. You will never be able to commit to a
ok. ?? RCP_5_0_2 looks like a revision off the RCP_5_0_2 branch to me. it is supposed to be the trunk. for this file. i understand CVS creates the branch off each revision number for each file, of wh
I'm converting from VSS to CVS (and I'm a CVS newbie). I found vss2cvs.pl as a script that will convert from VSS to CVS and have a question: Setup: CVS Server = CVSNT 2.0.41 running on a remote Windo