RE: .trunk patch refinement
If they've migrated from sccs, this will have been done for them :-) At 05:01 PM 6/19/00 -0400, Greg A. Woods wrote: snip However people should *not* ever be doing such silly things -- there are more corner cases than just this one whre they can get into trouble! snip
Re: .trunk patch refinement
On Mon, Jun 19, 2000 at 05:13:10PM -0500, David Thornley wrote: Mike Little referred to "some previous cvs admin", and this is precisely what happened in my case. Some previous CVS admin put some of the rev numbers to 2.x, and there's no way I can put them back to 1.x. You could probably do this using CVSFile (http://people.freebsd.org/~eivind/CVSFile-0.2.tar.gz) and a small perl script. This would, of course, invalidate any workspaces (checked out copies of the source) presently active. Note that I have not tested CVSFile with repositories that contain 2.x versions, and there may be bugs in CVSFile related to using such repositories - though as long as you don't directly overwrite your original repository, there should be no chance of data corruption. CVSFile lacks documentation - sorry about that. Eivind.
WinCVS bug? Tcl script looking up locked files
Hi all, I am pretty new to WinCVS so please forgive me, if I have overlooked something obvious. I want to write a Tcl/Tk script to check, if files are locked by someone (puting out only one line per file) Is there a script around, that I can use ? WinCVS 1.1b14 comes with a SelectionTest.tcl script, which seems to fullfil my requirements. Unfortunately the following statement does always return 1 (file locked) even on unlocked files ... loop over files cvsbrowser info $file fileInfo cvsout "-- Locked : " $fileInfo(locked) "\n" -- always 1, even for not locked files Is this a bug in cvsbrowser ? What is this cvsbrowser ? Please can someone direct me in the right direction. Thanks and best Regards, Hans
Re: .trunk patch refinement
Russ Allbery wrote : || David Thornley [EMAIL PROTECTED] writes: || || Either way, any technique that assumes that all main trunk development || is on rev numbers 1.* is useless to me, and probably to quite a few || people. || || And it's quite possible to get into that state without any misuse of CVS || at any point. It's worth remembering that a lot of us are using CVS || repositories formed from imported RCS files, and using different rev || numbers with RCS is extremely common. The sccs2rcs script in contrib retains such version numbers when it converts - many of my cvs managed files have version numbers greater than 1 because of this. With sccs, if you use -r9 (or -r99 or -r, whatever number of nines is needed to guarantee that it is bigger than the version number of any file being managed) it is the same as if you had used the current version for each file. I recall hearing that this doesn't work for rcs, but fixing whatever problem there is with this would make -r9 a workable approach. But making .trunk work is a better approach. -- Sleep should not be used as a substitute| John Macdonald for high levels of caffeine -- FPhlyer | [EMAIL PROTECTED]
Re: .trunk patch refinement
"Greg A. Woods" wrote: [ On Monday, June 19, 2000 at 17:13:10 (-0500), David Thornley wrote: ] Subject: Re: ".trunk" patch refinement Since it's a very natural thing to do, lots of people have done it. It's easy (and correct) to say they should not have done that, but the important fact is that it has been done. However the important thing now is to continue to deprecate that practice. Certainly. This does nothing to fix any existing problem. Nor does it help if somebody imports RCS files that have 2.x or higher rev numbers. That includes removing the instructions for doing it from the manual (and replacing them with dire warnings against doing it), and most definitely not adding new code that's expressly designed to handle only one of the corner cases that this sillyness introduces. Um, why not? And what are the other corner cases? If you use the rev number like a cookie, what problems are likely to result? In any case, one of the things we keep saying is never to use the rev numbers, and so you're claiming that the proper way to reference the head is to use the rev numbers? That looks like a kludge to me. So, since a kludge works on repositories that have never had a certain mistaken operation done to them (one that is easy and natural), you're against providing a clean way to handle the problem? (If someone found some way to clean up *all* of the corner cases, and if they could justify the effort this would take even in the face of the design goal of using symbolic tags to identify such things, then that might be a somewhat different matter) Are you saying that there might be a reason to change the rev number to 2.x or so? I don't think so. I think CVS works best, and is likely to continue to work best, when people treat the rev number as a raw identifier for the change. This doesn't mean that it isn't worth handling cases where somebody has previously changed the rev number. Mike Little referred to "some previous cvs admin", and this is precisely what happened in my case. Some previous CVS admin put some of the rev numbers to 2.x, and there's no way I can put It may be possible to renumber the trunk back to "normal", especially if there aren't too many branches in your repository There are too many. You can also leap-frog into a new repository starting fresh with "1.1" at some major milestone in your project. The actual amounts of use of history information is usually far lower than people surmise without measurements and indeed is extremely low if you only examine events where users back past a major milestone. You don't have to 100% cut them off from the old history either -- just keep it in a read-only repository for easy local access and then occasionally audit to see how often it's accessed before you retire it for good. We routinely have to change code that's three or four milestones back, when (for instance) a client runs into a bug. Keeping this code read-only is not acceptable. Further, we consider it important to be able to match source changes with the Gnats PR they are associated with. If we were to change the rev numbers, we'd have to find some way to change them in the PRs. This seems to me a major project to support a particular kludge. Another issue is that we can't invalidate everybody's workspace without major consequences. Most people have projects going pretty much all the time, and there's no time in which everybody's workspace is synchronized with the repository. Forcing such a synchronization is going to be expensive. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
6-20-2000 .trunk patch refinement
I have a new version of my ".trunk" patch (I sent it to bug-cvs already but I didn't want to pollute everyone's mailbox with a big patchfile twice, so I'm only sending this URL to info-cvs... Includes a new test case in sanity.sh for a revision "2.1" Changes to docs, comments...minor stuff. The patch applies to the development version of CVS. (and to 1.10.8, with a minor, easily resolved reject in log.c) (I did have some trouble with Larry's 6-19-2000 check-in to server.c, main.c, root.c though, so I ran the tests with those changes backed out.) http://www.geocities.com/dotslashstar/branch_patch.html -- steve __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/
.trunk patch, usage of -r1 random data point
Just out of curiosity, I used my hacked version of cvs to do this on my biggest repository: cvs rdiff -s -r1 -r.trunk topmodule diffs.txt There were 459 (out of 6658) files that had a revision number that didn't start with "1", and quite a few that I was surprised to see. (that is, quit a few relatively new files, in addition to the old ones. grumble grumble... silly users. :-) Just a random data point. -- steve __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/
WinCVS setup.
Howdy folks, I am setting WinCVS to connect to a Linux server where the CVS repository resides. I have setup the password authentication server and I seem to be able to login from WinCVS. However, I am getting an error in the status window. The error message is: TCL is *not* available, shell is disabled And when I go to the macro admin of the admin Menu in WinCVS, I do not see any of the modules in the repository. I only see TCL is not available. Do I need to setup something else on my Linux server or WinCVS. I looked through all the available doucmentation including the Don Harper WinCVS user guide and I didn't see any mentioning of TCL. If anyone can shed some light on this problem, it would be much appreciated. Thanks in advance. Kent Yang [EMAIL PROTECTED]
Re: When is it appropriate to update a major version number?
Mike Jellison wrote:
I don't understand why updating a major version number is a bad thing.
Conceptually speaking, there are two identifiers for any file under
configuration management: the
identifier-that-the-version-control-system-assigns-to-it-to-keep-track-of-it-for-its-own-purposes
and the
identifier-that-is-applied-when-your-configuration-management-process-determines-that-it-should-be-applied.
I'll call the first one the version control (VC) identifier and the
other the configuration management (CM) identifier.
When someone says they want to bump the revision number from 1.X to 2.X,
they are actually saying something like this:
"My project or file has reached a point where my configuration
management policy says that I need to "bless" it with a new identifier."
For example, their project may be ready for release, or their bug fix
tasks may be all completed, etc. Note that they are *NOT* saying the
following:
"I don't trust my version control system to know what it's doing, so I
want to change the internal mechanisms it uses to keep track of files."
...even though by monkeying with the revision numbers that's **exactly**
what they're saying. Hold that thought in memory for a moment.
The problem is that version control systems like SCCS (and some versions
of RCS, to a lesser degree) didn't realize (or didn't care :-)) that
there were these two identifiers. All you had was the one "revision
number". That revision number is of course the VC identifier
*only*--used only to uniquely identify a version of a file and for no
other purpose--and SCCS probably never intended it to work double duty
as the CM identifier as well.
But people are clever and crafty and realized that you *could* use this
VC identifier to store all sorts of policy information in a kind of
numeric code (2.x usually is shorthand for "part of the second release
of the product"; 3.1.1.4.5.7.2.3 usually means that you're way off on an
integration branch somewhere, etc. etc.). All you had to do was define
rules for how to interpret the numeric code. So they started shoving
all sorts of information into this poor little revision number and a
whole software release nomenclature was born (version "2.0" of a product
is more "mature", so it goes, than version "1.3").
Along came some latish version of RCS (I'm sure I'm mutilating VC
history here, but the thought's what counts :-)) which lets you mark
things with any old label you like (sort of). Voila: the CM
identifier. Now there was a version control system that *made explicit*
both the concept of a revision number--the internal VC identifier--and
the "tag" or "mark" or "label"--the public CM identifier. It was
expected that the revision number would no longer be used to store the
CM identifier information, since it was already being used to store the
VC identifier information.
So, recalling the earlier thought ("My project is ready to be blessed
with a new identifier for a reason dictated by my CM policy"), in RCS
you would tag certain *revisions* of certain files (identified by their
significant-only-to-RCS revision numbers) with the CM identifier--the
tag--of your choice, which could be a hell of a lot more expressive than
"2.X". For example, in my dumb example above you would tag the current
revisions (1.3, 1.56, 1.2947, etc.) of your files with, say, the tag
"RELEASE_2_2620". Now when you refer to files, you refer to them
using the public/CM identifier--RELEASE_2_2620--rather than the by
comparison rather scrawny revision number (which can now be left alone
by human beings to do its simple job of incrementing itself and keeping
track of branches).
So, you may ask, if the revision number is so all-fired internal to
systems like RCS and cvs, why provide the ability to update or mess with
it at all? A good question which is usually swept under the rug of
"backwards compatibility". The answer is, more forcefully, that ability
probably *shouldn't* be provided, but cvs is a good citizen when it
plays with old RCS files so it gives you the ability to mess around.
Why even provide the ability to see it? Because in between
CM-sanctioned versions of files may exist little unblessed revisions of
files that you discover (usually as a result of a drastic edit) you
need.
Finally, to state the obvious by now, cvs uses the notion of a tag as
the CM identifier and the revision number as the VC identifier.
Interestingly enough, you'll note that cvs handles vendor branches by
monkeying with the revision number which it has every right in the world
to do, as that number's only job is to uniquely identify a file (nothing
more, nothing less). So tag anything that might be interesting to you
later and get in the habit of referring to things by tags, not by
revision numbers.
So: a long answer, but I hope a useful one.
Cheers,
Laird
RE: WinCVS setup.
Kent, You will need to install TCL on your windows machine. I believe the link for this is: http://dev.scriptics.com/software/tcltk/downloadnow83.tml Tony -Original Message- From: Kent Yang [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 20, 2000 3:07 PM To: [EMAIL PROTECTED] Subject: WinCVS setup. Howdy folks, I am setting WinCVS to connect to a Linux server where the CVS repository resides. I have setup the password authentication server and I seem to be able to login from WinCVS. However, I am getting an error in the status window. The error message is: TCL is *not* available, shell is disabled And when I go to the macro admin of the admin Menu in WinCVS, I do not see any of the modules in the repository. I only see TCL is not available. Do I need to setup something else on my Linux server or WinCVS. I looked through all the available doucmentation including the Don Harper WinCVS user guide and I didn't see any mentioning of TCL. If anyone can shed some light on this problem, it would be much appreciated. Thanks in advance. Kent Yang [EMAIL PROTECTED] BEGIN:VCARD VERSION:2.1 N:Glover;Anthony FN:Anthony Glover ORG:ELMCO, Inc. TEL;WORK;VOICE:(256) 721-7714 x249 TEL;HOME;VOICE:(256) 837-7017 TEL;WORK;FAX:(256) 721-1816 ADR;WORK:;;6000 Technology Drive Building 1, Suite N;Huntsville;AL;35805;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:6000 Technology Drive Building 1, Suite N=0D=0AHuntsville, AL 35805=0D=0AUSA EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:19991105T195408Z END:VCARD
Merging from branch to mainline
New to CVS -- Help! For a production bug fix: - After creating a branchtag via "cvs rtag -b -r prodtag branchtag module" then, modifying files/unit and system testing - How do I merge the modified files back into the mainline/trunk of the CVS source? Thanks in advance for your reply(ies). Paul Adams -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 20, 2000 10:59 AM To: Brian Collins Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Repeatedly merging from branch to trunk Brian Collins writes: So, back to the branch, add another line (Line 3), commit it and merge it back to the trunk as above. This gives conflicts, thus: Line 1 f1 Line 2 on the trunk === Line 2 on the branch Line 3 1.1.2.2 when all I expected was the automatic merging of "Line 3"! Since the context is different, CVS isn't sure that it's actually put the new line in the right place, so it calls it a conflict and makes you verify that it is correct. *You* know that "Line 2 on the trunk" and "Line 2 on the branch" are equivalent, but CVS doesn't. -Larry Jones Ever notice how tense grown-ups get when they're recreating? -- Calvin
How to get CVS user (not system user) in a notification script
Hi, we are using "log.pl" in the loginfo control file to send out notification to developers on new check ins. We are using the passwd access and have a public cvs account (cvsuser) for users which are remote. CVS itself stores the remote user's name (let's say henry) for the log message, but the public cvs user name prints the public cvs user's name (cvsuser) because log.pl gets the name via getlogin() function within Perl. Is there a way to get the CVS author name at the time when the loginfo trigger is run? Thanks in advance, Uwe.
Re: Repeatedly merging from branch to trunk
Larry Jones wrote: Brian Collins writes: So, back to the branch, add another line (Line 3), commit it and merge it back to the trunk as above. This gives conflicts, thus: Line 1 f1 Line 2 on the trunk === Line 2 on the branch Line 3 1.1.2.2 when all I expected was the automatic merging of "Line 3"! Since the context is different, CVS isn't sure that it's actually put the new line in the right place, so it calls it a conflict and makes you verify that it is correct. *You* know that "Line 2 on the trunk" and "Line 2 on the branch" are equivalent, but CVS doesn't. OK, so, if on the branch the change had looked like this: Line 2 on the branch Line 2A and on the trunk it had looked like this: Line 2 on the trunk Line 2A then adding "Line 3" on the branch after "Line 2A" would *not* have resulted in a conflict? Regards, Brian -Larry Jones Ever notice how tense grown-ups get when they're recreating? -- Calvin -- "Everyone is ignorant, only on different subjects." (Will Rogers) Brian Collins Triple G Asia Pacific http://www.tripleg.com
[Q] multiple repository and patching changes
Hi, is it possible for CVS to generate all the changes I have made to a module and save these changes as a patch file? I'm asking this because I have two repositories and I wish to have CVS generate all the changes I have made on the first repository since the last tag and save the information as a patch file so I can apply the patch file to the second repository. ( I make most of my changes on the first repository and some changes on the second repository and they are, unfortunately, not connected by internet. ) If there is such functionality, what is the command ? Thanks.
Problem
Hello, I'm getting a problem (see below) whenver I try to a "get". I've checked the directories for '#cvs.wfl' or '#cvs.rfl' and can't see any. Has anyone seen this before? thanks! Brian Zieroth YellowGiant Corporation cvs server: failed to create lock directory in repository `/cvs/sql/data_model': Permission denied cvs server: failed to obtain dir lock in repository `/cvs/sql/data_model' cvs [server aborted]: read lock failed - giving up
Re: Repeatedly merging from branch to trunk
On Wed, Jun 21, 2000 at 09:32:03AM +1000, Brian Collins wrote: OK, so, if on the branch the change had looked like this: Line 2 on the branch Line 2A and on the trunk it had looked like this: Line 2 on the trunk Line 2A then adding "Line 3" on the branch after "Line 2A" would *not* have resulted in a conflict? Correct, except that CVS might require more than one identical line in between (eg. 2B, 2C, and 2D) to be confident that it had put "Line 3" in the right place. Of course, the problem would still be lurking; a year from now, someone would end up making a change too close to "Line 2", and would trip across it. The Right Thing(TM) would probably be to collapse (ie. "merge and forget") the branch and start a new one, rather than doing multiple merges from the existing one -- but I'm not quite sure how to do this in a context of ongoing bug-fixes to the previous release. The expedient thing, if the "Line 2 on the trunk" changes are fairly localized, might be to check them in on the branch, so that there's no longer a disagreement. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: Changing Revision with WinCVS!
Daniel Barsalou wrote: Can we reset the revision number of a file to 1.1? First off, I wouldn't do that if it were me. One of the major advantages of CVS, in my mind, is that you can go back to any old version of the file you like. And you always have that log and diff information if you need it. That said, if you REALLY, REALLY want to you can delete revision using the 'cvs admin -o' command. If you deleted all revisions except the revision you wanted, you COULD effectively reset the revision to 1.1. Make sure you backup your archive file before you start playing with admin -o. Derek -- Derek Price CVS Solutions Architect mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not celebrate meaningless milestones. I will not celebrate meaningless milestones. I will not celebrate meaningless milestones... - Bart Simpson on chalkboard, _The Simpsons_
Re: Win32 DLL for remote control of CVS?
No, but you might try www.wincvs.org. Derek -- Derek Price CVS Solutions Architect mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "If I was modest, I'd be perfect." -Ted Turner Jonah Goldshlag wrote: Hi, I'm not really sure if this is the address or the right place to be asking this, but I am looking for a little information about CVS, specifically about controlling it through calls to a DLL. I need to be able to control builds and branching from a remote machine, "getting" and "branching" my tree without having to go through a million command-line headaches. What I need is a DLL that handles all the calls to the server and simplifies my life a bit. Anyone know of such a DLL? Thanks for any help, Jonah Goldshlag
problems with winCVS (fwd)
This won't apply to most of you, but just be warned. There's a bug in WinCVS 1.0.6 (possibly only on Win2000) which causes newly-added directories to be added in upper case, regardless of the actual name of the directory. However, this only occurs when you use the menu to add, not with the right-click add. To spare you the details, if you need to add a directory, locate it in the left pane, right click, and Add. Same deal with commit. DO NOT use the "Cvs Folders-Add a Folder" option. Most of you don't. But it's a problem for new users because they tend to use the normal menus more frequently, and it will likely continue to be a problem with new users, so let 'em know. Incidentally, there's a beta version of wincvs @ wincvs.org with a vastly improved UI. I can't vouch for stability, but it doesn't exhibit this problem.
Re: file permissions with client/server
You can play with the CVSUMASK environment variable. I'm not completely sure how it works. See the manual. Derek -- Derek Price CVS Solutions Architect mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 151. H lp! S m b d st l ll th v w ls fr m m k yb rd! Mark Whitehouse wrote: Does anyone know how to set the directory permissions using client/server cvs to a specific value when directories are created with the cvs import command. I am running cvs 1.10.8 on a Linux RH 6.2 server. Thanks, Mark
RE: .trunk patch refinement
[ On Tuesday, June 20, 2000 at 10:41:16 (+0100), J. Cone wrote: ] Subject: RE: ".trunk" patch refinement If they've migrated from sccs, this will have been done for them :-) Yeah, no thanks to the broken use of sccs2rcs. Unfortunately nobody ever wrote an "sccs2cvs" that would properly translate an SCCS repository into CVS using CVS semanitcs. (I did do this by hand as an experiment once though, at least to see how some of the common cases would be handled, and it worked very easily.) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
