Re: CVS on a solaris box with ACLs
--- Noel L Yap [EMAIL PROTECTED] wrote: (I'm not convinced that CVS should directly support ACLs). FWIW, I've implemented platform-independent XML-based ACLs using perl5 regexes in my cvssupport project on Sourceforge. They're simply processed by a basic commitinfo script. You can block commits based on filename, revision or tag patterns, by user and role/group. Cheers, Laird = -- [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Does pre-commit script with a remote server?
Howard Zhou wrote: I am trying to write a pre-commit script to insert a change id to cvs log. Precommit scripts can't affect the file being committed, if by "precommit" you mean "fired by the commitinfo admin file". Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How can I Recover from Erroneous Checkins?
Deja User wrote: I know the cvs way is to keep the wrong version in the history and checkin the right one on top. But in my case this approach I need to just remove the wrong head revisions as if they were never there otherwise my revision hitstory ends up being littered with erroneous checkings and then checkings that are fixes to those checkins. Is there any particular problem with that? So there are some erroneous versions in a file's history. So what? Tag them with DO_NOT_USE or something similar. Check in early, often, broken, whatever: a version control system exists to track history, not pristine working copies of software. If you're still determined for some reason, you can use the cvs admin -o command, as in: cvs admin -o1.3 file.txt Note that just about any time you use the admin subcommand you're doing something that the authors left out of cvs for a reason. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multiple developers in one work area
"Parand T. Darugar" wrote: I'd like to setup CVS for a web based project that involves multiple developers. We would like to have those multiple developers access the same directory of source code, as opposed to each having their own working area. The reason behind this is that everyone needs to use the same web server for testing, and hence the same working area. No, follow the loginfo example in the manual (http://www.cvshome.org/docs/manual/cvs_18.html#SEC169) and write a script on the repository machine to copy files on checkin to the central area that needs to be updated. Then you can also control what gets pushed to the website. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs scripts
Greg Henley wrote: cvs status . | egrep "(status|Status)" | egrep -v "Up-to-date" cvs -n -q update also works very nicely, reporting what cvs *would* do if it *were* to do an actual update. Files that are *not* up to date show up in the listing with a "U" or a "P" (update or patch) next to them, indicating that they are out of date. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: verifymsg
[EMAIL PROTECTED] wrote: [another question answered explicitly by the cvs manual] http://www.cvshome.org/docs/manual/cvs_18.html#SEC166 Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS question
Vinh Pham wrote: Hi, For example, if there are 2 persons working on a project. If one person add a file or directory, how can the other person know that a new file or directory is added? Of course if the second person does an update (-d) , he or she will get that file/directory but are there any way to know this before doing the update. http://www.cvshome.org/docs/manual/cvs_toc.html Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Can't make root directory?
Stephen Rasku wrote: cvs -d :pserver:stephen@vancouver:/ash/cvsroot co /tgx/3rdparty/exim Oopsie; you said "/tgx..." instead of "tgx...". The argument to co/checkout is relative to the last component of the cvsroot specified as an argument to the -d parameter. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: notify file
"Derek R. Price" wrote:
There have been a few discussions lately about this kind of thing as
well, including one that suggested always providing all available
information for a hook in environment variables, similar to CGI, but I'm
not sure now that this patch isn't a better solution since it should be
harder to accidentally fill up a child's environment memory since an
administrator could pare the args going to a script when they _didn't_
want all the data. Of course, maybe some sort of pipe to squirt all the
data through as XML would be even better than that but I'm not sure I
understand all the issues here.
How about take a chapter out of the CGI/web book and shove all
parameters in url-encoded form on STDIN? Then people can use existing
code libraries/snippets to parse this string into name/value pairs.
Just like an HTTP POST form submission. Then you don't have to remember
which 2037 arguments to add to the script invocation in the *info file,
and the script's environment isn't filled up unless the script wants it
to be.
So here's an example (the following would show up on stdin of the
commitinfo program, let's say):
dir=foofilespec=a%7c1.2%7c1.3%7cOLD_TAGfilespec=b%7c1.1%7c1.2%7cOLD_TAGcvsroot=wherever
Running this through a standard URL unescaper (perl -MCGI -e 'print
unescape("dir=foofilespec=a%7c1.2%7c1.3%7cOLD_TAGfilespec=b%7c1.1%7c1.2%7cOLD_TAGcvsroot=wherever");')
yields:
dir=foofilespec=a|1.2|1.3|OLD_TAGfilespec=b|1.1|1.2|OLD_TAGcvsroot=wherever
...and running this through a standard webbish/libwww slicer and dicer
program you'd get (the following is my own syntax):
dir=foo
filespec=a|1.2|1.3|OLD_TAG, b|1.1|1.2|OLD_TAG
cvsroot=wherever
Or you could make the filespec syntax resemble the Entries file, if you
wanted. I've chosen filename|oldversion|newversion|stickytag
arbitrarily.
Cheers,
Laird
--
W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED]
http://www.amherst.edu/~ljnelson/
Good, cheap, fast: pick two.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: history of the tags (was: hitory of the tags)
Mike Sutton wrote: On 12/04/00 14:55:21, Youngman, James wrote: I would ideally like also to be able to restict how tags can be used (e.g. tags of a certain format can be used only in a certain way -- in my case, only on the top-level module and not directly on the modules it includes). Restricting and verifing tags is what the purpose of taginfo is. So you second argument contridicts your first. taginfo can verify your tags and log them. From the description of taginfo in the manual it would appear that you get a separate invocation of the script for each recursed subdirectory. Hence taginfo can't enforce the "only on the top-level module" constraint I mentioned above, as far as I can tell. Sure you can. taginfo gets the full repository directory. When the top directory is processed it can save a tempfile that the subsequent calls look for. Look at the log_accum script that comes with CVS. What is really missing is a post tag trigger. Or see my cvssupport project at sourceforge (https://sourceforge.net/projects/cvssupport). If you write cvssupport plugins instead of regular cvs plugins, you can control this behavior explicitly. The project is best accessed via (surprise) CVS at this stage; I'm still working on polishing the installation process. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help needed regarding verifymsg on branches
"Derek R. Price" wrote: Deivanai Meiyappan wrote: I have a template asking for BUG-ID when i am checking in at branch level..But i am not not able to get the branch tag in my verifymsg script. This would be a good problem to search the mail archives for. In short: parse current directory/CVS/Entries for the tag entry as described in http://www.cvshome.org/docs/manual/cvs_2.html#IDX39. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checking out a file (not a module)
ari gold wrote: the best solution i found was 'cvs update -d filename'.. that did the trick..makes sense, i guess. Right; as the fine manual states in zillions of places, you check out a project once. Then you do updates and commits till the end of time. http://www.cvshome.org/docs/manual/cvs_1.html#SEC5 http://www.cvshome.org/docs/manual/cvs_10.html#SEC85 http://www.cvshome.org/docs/manual/cvs_16.html#SEC121 http://www.cvshome.org/docs/manual/cvs_16.html#SEC150 Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Ampersand module question
I'm curious about ampersand modules. Once a regular module (containing another module via the "" construct) is checked out, does that module actually *know* that it contains the contained module? If my modules file says something like this: frobnicator frobnicator caturgiator ...and I do this: cvs checkout -P frobnicator ...then I get this (as expected): frobnicator/somedir frobnicator/caturgiator/someotherdir ...but now if I do this: cd frobnicator; rm -rf caturgiator; cd .. ...and then do this: cvs -q update -d -P -A ...then caturgiator does not reappear, suggesting that frobnicator's CVS directory does not record what the modules file engineered to happen. The only way to set this back up would be to re-checkout the project or checkout the caturgiator module directly at this level. Is that by design? Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Verifymsg on branches?
Alex Harper wrote: I'm fairly certain this will not work for the commit -r case Laird mentioned, but since 99% of my users are using GUI CVS clients which do not have a commit -r interface anyway I decided this was a hole I could live with (given no other choice). FWIW, that's the same approach I used. Loginfo supplies a lot more information than any of the other CVS hooks, the problem for me was that by the time the loginfo runs you can't stop the commit. Its already happened. So while you can warn the user that they didn't include a bug number you can't actually _make_ them do anything at that point. Right. About the only thing you could do is something really fancy, ugly and evil involving another cvs invocation--like a cvs admin -m or something. If someone with more CVS hook experience than I knows of a hole in the above suggestion please let me know... Nope, that's about right. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Verifymsg on branches?
Uwe Fritsch wrote: Instead of changing the entered log message after the user has entered it, I rather would like to make the user aware that he has to enter a Bug ID in the log message. My idea was to have a different log template for the trunk as compared to the branch. As this seems not possible, I now think it would be enough to add the BugID line to the generic template and only do the test whether the Bug ID was entered if the commit is done on the branch. OK. But if you can't check for a tag name at verifymsg this will also not work, right? The only possibility would be to check for a "branch version number", i.e. 4 digits instead of 2. Well, you can look at the current-directory/CVS/Entries file in your script and parse it. The last or next to last (I forget) field on the line is the sticky tag the old version of the file has. Note that this method breaks the minute anyone uses a cvs commit -r operation. Finally, you *could* do something really ugly in your loginfo where you would make your script do something like this (warning: untested; seat-of-the-pants coding): cvs admin -mNEW_REVISION:"INVALID REVISION; DO NOT USE" # or something like that cvs update -p -rOLD_REVISION realfile tempfile mv tempfile realfile cvs commit -f -m "Rolled back commit because log message was invalid" realfile ...and then bitch really loudly and graphically to let the user know his commit was effectively rejected. I wouldn't really recommend this, but this would ensure that you could keep non-standardized commits out of your source tree. They'd actually be in there, but not very accessible. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Verifymsg on branches?
Uwe Fritsch wrote: we used the verifymsg mechanism in the past to check for some keywords for commit messages. As we create a branch for each release, we would like to add an additional keyword for bug numbers, but only if a new version is committed to the branch. Well, you can't really do this (yes, you SHOULD be able to). This is due to two major things: 1. You cannot get the new version number of a file being committed. So you'll never know if that file is going onto a branch or not. The best you can do is guess based off the old number of the file. This works for most cases, as most users aren't using the -r switch to cvs commit. 2. You can't add anything to the message at commitinfo or verifymsg time. The message being verified is read only. What you *could* do is do something really clever with loginfo. Basically, since loginfo gives you the old and new version numbers, you could invoke cvs admin -m (haven't tried this; don't know if it's supported; rcs -m lets you replace one version's log message with another) if the new revision number contains more than one period in it. The other thing to do would be to apply your new keyword as a tag instead. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Updating file versions from 1.x to 2.x
Michael Bailey wrote:
I've been asked to update file versions for all files on a branch to 2.0
Although I realise this is not the cvs way, would it be A Bad Thing?
{sigh} It's a shame you're dealing with a boss who most likely has only
ever used or heard of SCCS, which doesn't have labeling/tagging
facilities, and is hence usually the culprit for people's wanting to
change opaque revision numbers to 2.0. Oh well.
It shouldn't be a bad thing. The command we had to use around here
(when we were working with just such a boss) was something involving cvs
commit -r2.0 -f *.yourfileshere in each directory. This is always a
sign that someone is ordering you to do something that they don't
understand, but it works.
(Far saner, just so I say it and get it out of my system, would be to do
this:
cd /your/sandbox
cvs update -d -P -A
cvs tag A_LABEL_THAT_MAKES_SENSE
...and then if you ever need to get a file corresponding to that label,
you'd do this:
cd /your/sandbox
cvs update -r A_LABEL_THAT_MAKES_SENSE theFile.txt
This is usually the only use case that your modern version control
system ignorant manager is trying to accomplish, and so upping
everything to revision 2.0 is the wrong way to go, as you indicated you
know.)
Cheers,
Laird
--
W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED]
http://www.amherst.edu/~ljnelson/
Good, cheap, fast: pick two.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
sleep 2 in loginfo example
The CVS manual speaketh thusly: "C.7.2 Keeping a checked out copy "It is often useful to maintain a directory tree which contains files which correspond to the latest version in the repository. For example, other developers might want to refer to the latest sources without having to check them out, or you might be maintaining a web site with CVS and want every checkin to cause the files used by the web server to be updated. "The way to do this is by having loginfo invoke cvs update. Doing so in the naive way will cause a problem with locks, so the cvs update must be run in the background. Here is an example for unix (this should all be on one line): ^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs; cvs -q update -d) ) $CVSROOT/CVSROOT/updatelog 21 "This will cause checkins to repository directories starting with cyclic-pages to update the checked out tree in `/u/www/local-docs'." I'm interested in the "sleep 2" command. I understand needing to run cvs update in the background to avoid locks. I don't see what the sleep 2 is for. (I'm writing a script to automatically cvs rtag commits, and am trying to figure out the sanest way to do it.) Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: access rights to branches
[EMAIL PROTECTED] wrote: When might the patch referred to below make it into a future CVS release? Probably about the same time that the cvs edit -c patch does. :-( Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: access rights to branches
Shem Mazur wrote: I have a CVS user who continues to checkout modules or update files from the wrong branches. Can I restrict her ability to update from particular branches or main trunk? What the various other replies were trying (somewhat unhelpfully :-)) to tell you is no, not with CVS out of the box. With its commitinfo mechanism you can't get access to either (a) the new revision number prior to the commit taking place (a feature that sure would be nice to have) or (b) whether or not the user supplied a -r switch to the commit command. If you could get either (a) or (b) then you could reliably block commits onto a branch. That said, if you know that your user will never try to force a commit using the -r switch (don't know how you'd know this, but most users don't use this flag), then you can write a commitinfo script that will check the old revision number and reject access based on it, making the assumption that the new revision number will be the old one with the rightmost number incremented by one. You could also check the tag. I've got a project going that lets you do this with an XML file declaring who can do what. Branch commits (with the assumption made above) can be blocked based on any combination of filename pattern, revision pattern and/or tag pattern. Look at the cvs archives at http://sourceforge.net/projects/cvssupport/. Hope that helps, Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: access rights to branches
Andrew Gilmartin wrote: What would be useful to us is a pre-commit check that made sure the user can revise a given file and given branch or mainline. For example, # user file development-line * #none #none * com/mesasys/productA/* release_4_branch asdcom/mesasys/productA/file1 patch_1_branch,patch_2_branch,patch_3_branch bnmcom/mesasys/productA/file1 #mainline,patch_*_branch cvbcom/mesasys/productA/* #all This configuration would give 'asd' access to file1 only for patching, 'bnm' access to file1 for patching and mainline development, and 'cvb' all access to all files in all directories on all development lines for productA. Otherwise all developers can commit changes to release 4 of productA and no developers can commit other changes elsewhere. Right, or see http://cvssupport.sourceforge.net/cvsacl.dtd for an XML DTD that defines another syntax. Maybe I'll look into adding the above syntax as well. I don't think this can be done currently as the commitinfo handlers you do not have information about the line of development -- branch or mainline or revision numbers. If you did then implementing this kind of access would be straight forward and I think quite valuable. Perhaps we need a commitinfo2 that provides this kind of information on the command line to the commit handler. Again, if you can live with the assumption that the -r switch will never be used in conjunction with the cvs commit command, then you *can* implement this stuff (but it can always be overridden with the -r switch). The information is there, it's just in horrid locations and ad hoc bits. My cvssupport project (a) normalizes all the available information into a set of perl classes and (b) provides a flexible ACL plugin that allows you to do the above. See http://sourceforge.net/projects/cvssupport/ for details. A full announcement will follow when this project is ready for prime time; in the meantime of course you can look at the sources via SourceForge's cvs access mechanisms. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Getting the version number in a notify message
Aldo Longhi wrote: As far as I can see in the CVS documentation (Cederqvist), this information is NOT passed to the "notify" script by CVS (as it is for other "trigger" operations). Actually, the new revision number is only passed to loginfo. Everything else (commitinfo, verifymsg) suffers from the same problem you're having. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
What *should* happen in a cvs update from top level dir?
I'm using cvs 1.10 on Solaris 2.7, built from source. If I have a projects directory and I check out two modules into it, and if I have any CVSROOT environment variable set, and if there is no CVS directory inside the projects directory, what should happen when I do a cvs update from within projects? Visually here's what *does* happen: % mkdir projects % cd projects % setenv CVSROOT :pserver:me@somewhere:/cvsroot/wildblueyonder % cvs -d:pserver:me@somewhere:/cvsroot/wildblueyonder co -P somemodule % cvs -d:pserver:me@somewhere:/cvsroot/somerepo co -P someothermodule % pwd /users/ljnelson/projects % ls CVS CVS: No such file or directory % cvs update protocol error: directory '/cvsroot/somerepo/someothermodule' not within root '/cvsroot/wileblueyonder' % Note that without the CVSROOT environment variable set, cvs won't even try to dig through the subdirectories at all. And, as indicated above, *with* the CVSROOT variable set, CVS is happy to dig through the first level of subdirectories, but uses the environment variable instead of the CVS/Root file in each module. I have a colleague who is asking how he can effectively issue a cvs update from the projects directory and have all of his checked out projects (from various cvs roots) update themselves. I was surprised to note that cvs update will dig around in the subdirs one level under where it was invoked, but not any deeper, even if it's invoked in a cvs-unaware location. Any comments? Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT problem
- Original Message - From: "Rafal Kedziorski" [EMAIL PROTECTED] I want to lock the access to CVSROOT for users. Only the admin of the repository should change it. How do I make that? If you just want to prevent people from modifying certain files, you can use your filesystem's read/write bits. Just make sure that the files in the CVSROOT module on the repository machine are chgrp'ed to a group that only admins can be part of, and then make them group writeable. If you're interested in: (a) being able to stop people from doing the above (b) being able to prevent people from adding and removing tags based on file name, file revision and/or tag name (c) being able to prevent people from committing on a branch (d) being able to freeze a project (e) being able to work around cranky repository administrators (i.e. "all users contacting this repository via pserver are mapped to a single user id so that the repository machine only has one system account on it" -- this kind of policy prevents you from using regular filesystem security!) (f) being able to maintain access control list information in a moderately readable format ...keep an eye on http://sourceforge.net/projects/cvssupport/. I'll be releasing files there by the end of the month. Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Philosophy question regarding modules file options
What was the intent behind the -o, -u, -e, -i, -t, etc. modules file options? I understand that they are the ancestors of the commit support files, but some of them run their programs on the server side, some on the client, and (it seems) all of them run only after the operation has completed. I guess what I'm wondering are things like this: * What was the rationale for saying that the checkout (-o) option causes the program to run on the server side, while the update option (-u) causes the program to run on the local/sandbox side? * What was the anticipated use or intended use for the -o option in particular? Did these options also predate the history mechanism or something like that? * Can any of these options be used to *prevent* their operations (the manual sez no)? The missing piece in terms of access control seems to be preventing someone from checking out a module; I can't off the top of my head think of any way to block this. Thanks, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: commitinfo variables
"Alexander N. Spitzer" wrote: are there anymore variables then just $CVSROOT $RCSBIN $USER $EDITOR i.e. is there a variable with the command line params in it/and or tags? No. But note that taginfo provides you with the tag that the person is adding, moving, or removing, so perhaps that's what you want? If not, I think this would be a great addition. Yes; you are quite right in general--the interface for these programs is piecemeal and inconsistent. Incidentally, you can't get other things that would be nice to have, like the proposed new revision number before the commit happens (so you can't therefore prevent commits that are going onto particular branches), or whether a branch tag is being applied or just a regular one. See http://sourceforge.net/projects/cvssupport/ for my attempts to expose as much of this scattered information that's *already* available in a clean perl OO sort of way. Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS_USER
"Derek R. Price" wrote:
Also, it sounds like with this method large lists would be processed and
placed in the environment regardless of whether the child was going ot
use them or not. i.e. CVS could go through and place a 1000 item list of
filenames in the environment for a script called from taginfo even though
the script was only going to check whether the user was on a list of
admin users.
Each script fired by a commit support file is fired once per directory.
So in the usual case, where people don't store 1000 files in a single
directory, this would be a non-issue.
Put me down for +1 in favor of either (a) putting this information in
the environment so I don't have to remember what arguments go where or
(b) loading my commitinfo scripts via dlopen() or some other dynamic
in-core solution. Given the current architecture I'm more in favor of
(a).
Actually I'd be most in favor of writing a pserver implementation in
perl and dynamically including perl modules, but that's a whole
different story :-) :-) :-)
The project I'm working on at
http://sourceforge.net/projects/cvssupport/ lets you write perl modules
that override methods to handle parts of the commit process. If you
need some piece of information, like a filename or an old revision, or
what the best guess is as to what the new revision number will be, and
so on, you call the appropriate method, which defers looking that
information up as late as possible. The nice thing about this approach
is that regardless of what the scripting interface turns out to be
(environment vs. DerekPatch (tm)), I can still keep a simple interface
into something most sysadmins are used to, viz. perl modules.
So you do this:
sub commit() {
my $self = shift;
if ($self-get_filename() ne 'foobar.txt'
$self-get_old_revision() ne '2.4') {
# vote for rejection of the commit based on this
# silly conditional
return 0;
}
}
...instead of writing a shell script or something else that parses
through argument lists.
Speed, incidentally, is less important to me, FWIW, on tools like this;
by the time I commit or tag something I'm psychologically resigned to
its taking a long time anyway (I'm done doing whatever I was doing,
after all), and as far as space and memory go, the cvs repository binary
is usually running on a big fat server anyway. I'd be much more in
favor of loading the environment (or whatever) up with a lot of info,
rather than putting it on demand in odd places.
Cheers,
Laird
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository know who has checkouts?
From: "Noel L Yap" [EMAIL PROTECTED] What about getting rid of "cvs watch on/off" altogether and making this feature a configuration parameter inside CVSROOT/config? Bingo. Exactly what I had in mind just this morning. :-) Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Permissions on cvs watch on/off (Was: Repository know whohas checkouts?)
Noel L Yap wrote: I haven't formed an opinion, yet, but I will say that allowing only cvsadmin to use "cvs watch on/off" may be more difficult than protecting "cvs admin" since there are sub-sub-commands to "cvs watch" that normal users should be able to use. Well, right; my point I guess is that cvs watch on is a different sort of command altogether than cvs watch add. The fact that they happen to be subcommands is probably just a coincidence or the result of rapid development. Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository know who has checkouts?
"Derek R. Price" wrote: Well, I view the 'chmod u+w' or 'cvs edit' requirement as a side effect of a user watching those files. CVS has to be running in order to send the notices user A requested, so user B has to run 'cvs edit' when he wants to edit or else there won't be a running process that knows to send the notification to user A. The alternative seems to be some sort of kernel daemon or a periodic cron job watching access times to send the notices. Or maybe a wrapper script for every editor the user could use which looks for a CVS directory, checks permissions, then calls 'cvs edit' if it deems it necessary. I think all of these solutions would be daunting for many users to install. Possibly even nightmaric to automate in a distributed project, as I imagine many open source projects are. Take SourceForge as an example if you like. Hmm... distribution scenarios come to mind, but they're all extra work anyhow. I'm sure requiring users to tell CVS they were ready to edit seemed the most expedient at the time the feature was added and remains so. Agreed entirely. The only bit of this whole watch on/watch off (Karate Kid, anyone?) discussion that I find odd is on the non-technical level, which you don't really address above, viz. that *any* user on the project located *anywhere* can cause my sandbox to behave differently than it did yesterday (when next I perform an update, of course). The thrust of my comments is this: I'd prefer "any user" to be replaced with "a designated user", and "anywhere" with...well, location doesn't really matter. :-) To put it another way, if I got into the rut previously of just editing a file and not having to run some command first, then I don't want that rut to change unless someone on my project who is authorized to cause such changes makes it happen (that's better communication, actually, than letting any user mess with my development habits). (Again, this is mainly because our user base consists of people who look at cvs distrustingly to begin with; any perceived-to-be-random changes that occur are likely to make them bitch and whine at me. :-)) Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS timestamps
Matthew Berney wrote: It would be nice to have the timestamps in the repository actually match our local time Oopsie; you don't want to do that if your repository is global, like most, say, open-source projects. I'd vote for client localization, though; i.e. cvs logs and historys and so on should report local time for you. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Directory-level access control?
"Derek R. Price" wrote: Yes. You can do it using standard UNIX permissions groups. Also take a look, if you're the open source hacking type, at http://sourceforge.net/projects/cvssupport/. I'm working on a project there that, among other things, will allow XML files that conform to http://cvssupport.sourceforge.net/cvsacl.dtd to govern commits and tags. I'll announce its availability to this mailing list when it's in a state that won't endanger the populace. :-) Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs commit confusing behaviour on modified files without changed content
Olivier Berger wrote: As cvs has connected to the server, it detects that the content hasn't changed, and doesn't commit anything without notifying me. So everything looks like the commit aborted for some unreported reason. What do you think about that (client 1.10.7 - server 1.10.6) ? I think you can use the cvs commit -f option, which forces the commit to take place (perhaps put it in your .cvsrc). :-) Be forewarned that sometimes this used to crash cvs 1.10; I'm not sure about 1.10.x. Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository know who has checkouts?
"Richard J. Duncan" wrote:
We add a
watch to the entire source tree. Then when people checkout code they
must run "cvs edit" to get a writable version of the file before
making modifications
What does it mean to say "cvs watch on" across a sandbox? Does that
really mean that the actions of one user (the guy who did the cvs watch
on) can affect everyone else's sandboxes (now everyone has to type cvs
edit to edit those files that cvs watch on was just run on)?
The cvs editors command then call tell you who has typed "edit" on a
given file. The information is tracked in the repository CVS/fileattr
file.
[snip]
and it will look something like this:
Fsdb_02.cc _watched=;_editors=pengTue Oct 3 20:50:08 2000
GMT+isip207.isip.msstate.edu+/isip/d207/peng/tools/class/shell/Sdb;_watchers=pengtedit+tunedit+tcommit
Looks like the format is:
_token=optional value;_another token=another optional value
What's the significance of something being watched ("_watched=;") but
that doesn't have any watchers?
Cheers,
Laird
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository know who has checkouts?
Noel L Yap wrote: No, unlike some other tools, changes within the repo do not affect already-existing working directories (aka sandboxes). I was probably unclear. If user A sets a watch on somefile.txt, then *when user B updates his copy* it will come down as read only, *even if there are no settings anywhere in user B's world that would otherwise bring a file down read only*. User B's world has just subtly changed; without understanding why, now he just knows that he can't simply open that file in a text editor anymore, even though he knows he didn't change any environment settings, any file permissions, etc. If user B now gets smart and figures out what's going on and therefore does a cvs watch off on somefile.txt, then the next time that user *A* brings down somefile.txt it will not come down as read only (as he might have thought) but as read/write. So user A's sandbox activity can affect the kinds of updates that occur later in user B's sandbox, and vice versa. Verified using cvs 1.10 on Solaris 2.7 using two users and a pserver repository. You can envisage "watch on" and "watch off" wars among the unwashed masses. :-) Anyhow, it's kind of a minor point, but it is a little odd, don't you think? Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository know who has checkouts?
Noel L Yap wrote: Yes, this would be a problem. In practice, though, the entire team decides to use "cvs watch on" on the entire repository (or at least entire modules) so that they may use "cvs edit" to better support inter-team communication. Right. Before I go and cvs watch on various files I want to alert people to what's coming, that's all. Thanks for your help! Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository know who has checkouts?
Noel L Yap wrote: Yes, this would be a problem. In practice, though, the entire team decides to use "cvs watch on" on the entire repository (or at least entire modules) so that they may use "cvs edit" to better support inter-team communication. It just struck me that watch on/watch off is in exactly the same sort of camp that cvs admin is, yes? So shouldn't it be protected by the cvsadmin group? Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Memory/space issues
Paul Sander wrote: Which device are you looking on? The Entries.Static file is normally created in your workspace. Might that device be filling up? --- Forwarded mail from [EMAIL PROTECTED] I am somewhat new to CVS, at least as the admin... I am running into problems of when trying to do a CO or a CI it is failing, and i am getting an error like: [root@tango build20]# cvs co -r build20 myhost.com/HTDOCS cvs [server aborted]: cannot open CVS/Entries.Static: No space left on device There is most certianly space on the device, to the tune of several gigs... (trying to check out 20-30 MB) --- End of forwarded message from [EMAIL PROTECTED] Data point: remember that No space left on device can also signify that the number of inodes allowed in your system is used up. That is, the permissible *number* of files (which is normally enormous) is being exceeded. Well, that was a problem we were having anyhow. Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Check out trigger
[EMAIL PROTECTED] wrote: I am desperately trying to have a trigger set up for check out. You are out of luck. Time to start hacking C code. :-) Is there some reason you can't continue to use your modules -o solution for all modules? Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Entries format question
I'm finding a case where there's a '=' in the date field of a line in an Entries file when I'm doing a cvs tag. The = is not documented in the Cederqvist as being one of the characters that should show up in the timestamp field. I'm running a taginfo script under pserver that parses the Entries file it finds in the cvs-servpid directory (its current directory when it runs, actually) (more for curiosity at this point--to see what's in there in the tmp directory when a cvs tag happens) and I'm finding a line like this: /theFilename.txt/1.23/=// Cederqvist says, in http://www.loria.fr/~molli/cvs/doc/cvs_2.html#IDX81, paraphrased, that anything that shows up in the timestamp slot that isn't a date/time string means that the file is to be considered modified. Was the '=' picked for any particular reason or is it just there to indicate that theFilename.txt is to be considered as "modified" in some way since the tag operation should complete even if no lines in the file have changed? Cheers, Laird
Taginfo question
Is there any way to determine from within a taginfo script whether the tag being added is a branch tag? I'm inclined to say no--no such information exists in any of the arguments etc. passed to taginfo, in the ,v file or in the environment. Cheers, Laird
inetd question related to cvs (not usual pserver doesn't work FAQ)
inetd programs are supposed to be able to simply read from STDIN, right? I'm trying to write a wrapper program around cvs pserver that gets invoked, obviously, from STDIN. I'd like to peek at the conversation between client and server, and I thought I could get at this conversation by simply reading from STDIN. But my program blocks infinitely. Is the cvs client/server protocol such that it is started by the server (the Cederqvist says no)? In case it matters, my program is a perl program. Cheers, Laird
Re: Taginfo question
Another taginfo question (maybe a bug report).
Cederqvist says that the taginfo script is supposed to get five
arguments: tag, action, directory, file and revision.
But when I do a cvs tag -d someTag someFile.txt I get three: tag
("someTag"), action ("del") and directory ("wherever/someFile/lives").
Is this a bug?
Cheers,
Laird
Re: inetd question related to cvs (not usual pserver doesn't workFAQ)
[EMAIL PROTECTED] wrote: An easier way to look at the pserver client/server dialog is to define the CVS_CLIENT_LOG environment variable with the base file name for the log on the client. Yes; thanks. What I'm actually trying to do is harvest some information from the pserver connection that should be exposed to commitinfo and the like (like the -r option to commit--if someone commits a file and says -r 2.4, there's no way to get that 2.4 inside a commitinfo script). If there's a way to get these kinds of things with stock cvs, I'd like to do that. Anyhow, I thought I could sniff a bit of extra information via a server side wrapper and then pass it on (in the environment, perhaps) so my commitinfo scripts could make use of it. Guess I can't really do that. Cheers, Laird
Re: Wrong Author entry when using log[_accum].pl
Martin Neitzel wrote:
FYI, this escaped me in the Cederqvist because this special variable
substitution appeared to me as a regular environment variable with
its regular $SYNTAX and all the other shell piping / redirecting,
and quoting being used in the examples.
Yes; IMHO the Cederqvist needs to be updated. I had to be set straight
myself by Larry Jones earlier. :-)
And now, a related tangent (can there be such a thing? :-)):
For anyone (particularly perl folks) who has tried to write backend
scripts that do complicated things (as opposed to simply mailing
something somewhere), I think you'll find my upcoming cvssupport package
useful (http://sourceforge.net/projects/cvssupport/). There will be,
among other things, a program called something like cvs_harness (a perl
program) that you "install" into each of your *info and verifymsg files
like this:
DEFAULT /path/to/cvs_harness --script=commitinfo
--plugin-registry=/some/file ${=PID} $USER
...(that's a commitinfo example). Then you write perl plugins that all
have the same interface. The harness normalizes all of the bizarre
arguments, variable expansions, etc. that go on among the various *info
files.
So remembering, e.g. that taginfo takes five arguments and gets called
once per file but commitinfo gets called with batches of files in the
same relative directory and loginfo gets its log message on STDIN but
verifymsg gets ITS log message in a file in the temp directory are all
things of the past. Instead you write perl like this:
# ... somewhere in your plugin
sub commit() {
my $self = shift;
my $status = 1;
# oo, acl stuff. Read on in the message.
my $acl = new CVSSupport::ACL("some/file.acl");
for ($self-get_file_entries()) {
unless ($acl-check_permission(user = $self-get_user(),
action = $self-get_action(),
file = $_)) {
return 0;
}
}
return $status;
}
...that works on an acl file something like this:
?xml version="1.0"?
cvsacl
security-constraint
fileset
!-- Note the perl 5 regex below --
file-pattern^whackme.txt$/file-pattern
revision-pattern^2\.\d+$/revision-pattern
/fileset
role-namenormal-users/role-name
!-- Basically says that normal-users can add, modify and remove
a file named whackme.txt only if the revision
being committed is 2.x (bizarre) --
file-action
action-nameadd/action-name
action-namemodify/action-name
action-nameremove/action-name
/file-action
/security-constraint
/cvsacl
The package will have a CVS::ACL plugin which will allow you to
selectively prohibit commits based on pretty much any combination of
(using full perl 5 regular expressions):
* filename
* file's old revision
* file's new revision (where possible)
* file's tag
* tag pattern
* branch names
...as the simple example above indicates. The acl is role-based and
looks surprisingly like the deployment descriptors of Java's J2EE
standard.
I say this is all future because of course I'm working on it in my spare
time at home. :-) I'm about 85% of the way towards a first cut
release; the ACL stuff is working as is the plugin machinery, but there
are various bits that need to be polished up a bit. The whole thing
SHOULD work on rsh/ssh, local and pserver deployments; I haven't tested
using gserver or any of the kerberos-type deployments. It's probably
best used with pserver, as that's what I'm mainly writing it for.
Cheers,
Laird
Re: Wrong Author entry when using log[_accum].pl
- Original Message - From: Martin Neitzel [EMAIL PROTECTED] I can give you a simple patch setting the environment variable CVS_USERNAME to "roland" (while keeping USER as "cvsiti"), as well as my own loginfo logger using this, as well as adding a corresponding email address if present in the "users" file. Folks are aware, I hope, that the functionality of this patch is already exposed by CVS and documented in the Cederqvist? You don't use an environment variable to get at it, you use a "user variable" in your commit/loginfo scripts. So your commit/loginfo line would look like this: # example DEFAULT /your/script/here $USER Then it's up to your program, of course, to extract the first argument from its command line and treat it as the name of the real CVS user. And yes, you really do type the string '$USER' on the line above. And it really does behave correctly, even in the most confusing of pserver setups. :-) logaccum.pl or whatever it's called should probably be updated to use this variable to prevent this patch from being needlessly applied. Cheers, Laird
Re: Security Problems with CVS?
[EMAIL PROTECTED] wrote: Have you consider useing CVS together with SSH ?? This message triggered something I've wanted for a while. Could someone who is proficient in ssh and WinCVS in particular post a step-by-step tutorial on how to get the two to play nicely together in a way such that one does not have to enter one's ssh password for every single WinCVS command? For example, SourceForge has a nice HOWTO on the subject, but they recommend using an ssh setup that requires you to enter a password for every single command. There must be some intricate way to avoid this that I'm missing. I'm sure I'd not be the only one who would appreciate this. Cheers, Laird
Re: CVS checkout filename with space (bug fixed ??)
Laine Stump wrote:
I have files with spaces in them (not by choice - InstallShield saves
some project info in files containing spaces in the names), and the only
trouble I've had is spurious messages when doing cvs update from a
parent directory of the directory containing the "spacey file". add,
checkout, and commit work just fine (from the cvs commandline, at
least).
The place where there is LOTS of trouble (not insurmountable, but close)
is in the whole {commit,log}info/verifymsg mechanism. If you don't run
any scripts off the back of your cvs installation, you're right; as long
as you quote things stuff generally works.
Cheers,
Laird
Re: CVS Code Freeze and 1.11 Test Release Available
Noel L Yap wrote: It's interesting that none of "cvs edit -c", "cvs edit -f", and "cvs ci -c" made it into this release Damn! OpenAve: PLEASE put these in. We desperately need them. Hopefully the WinCVS folks will incorporate them as well. IMO, these patches are extremely important in that they satisfy most users who want reserved locks while not making irate those who prefer concurrent development -- it's the best of both worlds. Exactly. One more vote. Cheers, Laird
Re: Questions about CVS tags
mich wrote: Does anyone on the list know what is causing the error below: == RESPONSE has 0 items: cvs [server aborted]:tag '.' must start with a letter == Yes. Your tag that you are applying seems to be simply '.'. Tags must start with a letter. Or was the error message not helpful enough? :-) Cheers, Laird
Re: how to create/design your repository/project
[EMAIL PROTECTED] wrote: How should I set up my repository to best benefit the development/management effort? should we have multiple repositories? each repository represents one of our clients. or should we have just 1 repository, define multiple modules and each module represents one client/project combination? My company has played around with various approaches. We started out with the one-repository-many-modules model, which we didn't particularly like for some reason that now escapes me, and then moved to a one-repository-per-project model. I don't really like that either. Finally, it looks like we're settling on a one-repository-per-functional-group model, so the infrastructure group has their own repository with potentially several modules in it, the client-facing teams have their own repositories with potentially several modules, and so on. Hope that helps. Cheers, Laird
Re: [Cvsnt] Security pserver ..
Tony Hoyle wrote: I found an ssh client! Unfortunately WinCVS doesn't like it when it asks for a password (it hangs). It was also more than a little opaque to set up (nothing that couldn't be fixed with scripts though). Mike Castle on this list claims there's an easy way to get ssh working with WinCVS. I'm hoping he'll post this method to the list, as it would benefit lots of us. Grep through the archives to find his earlier message. Cheers, Laird
Re: Code freeze support in CVS?
Dennis Jones wrote: Does CVS support the idea of code freezes? For example, being able to restrict commits on a particular branch, directory, or file, or by user groups (via commitinfo perhaps)? Keep an eye on http://sourceforge.net/project/?group_id=8435 (the nascent and currently rather frail and naked CVSSupport project). There's a piece of code (a commitinfo script) in its repository at the moment that currently restricts commit access to the main trunk, but if you know perl somewhat this can be easily hacked to restrict access based on just about any criteria you like. The intent of the project is initially to get some kind of a sane interface layer (in perl at least; possibly other quickish cross platform languages later) to the bizarre *info triggers into which anyone could snap "plugins". Ultimately I hope this project will drive the official development of a better trigger mechanism in the official release of cvs, but until it gets there, this should help out somewhat with requests of this kind. Cheers, Laird
Re: CVS pids and the pids of its kids
"Reinstein, Shlomo" wrote:
Hi,
I've used that method to communicate information between the commitinfo and
the loginfo of the same commit process - that is, using the pid of the "cvs
commit" process itself, which is the parent of both.
How have you done this? The pid of the "cvs commit" process itself is
NOT the parent of both commitinfo and loginfo. The fork-and-exec
happens (apparently?) *after* the commit actually occurs. This means
that commitinfo and verifymsg are run by the same pid, but loginfo is
not. As the Cederqvist manual says somewhere, the order of the relevant
*info scripts is this:
1. commitinfo
2. verifymsg
(commit happens if (1) and (2) let it happen)
3. loginfo
(1) and (2) are run by the same parent pid; (3) is not.
Just one point: In case
you don't work with a CVS server, and people can access the repository from
various machines, the pid is not enough for distinguishing between commits,
you need to use both the pid of the commit process and the name of the
machine.
Yes, of course. {whap} Duh.
Cheers,
Laird
Re: CVS pids and the pids of its kids
Donald Sharp wrote: Have a control file that tracks directory names based on the original cvs invocation pid.The commitinfo script would write to this file the location of it's temp directory. Where do you propose to keep the control file? How do you know what cvs' original invocation pid is? If you can come up with a suitable random answer (i.e. the name of a directory that won't stomp on some already existing directory under heavy cvs or inetd load), then I don't need all this PID stuff at all--or the control file, for that matter--because wherever the control file would be written would itself be a suitable place for all the scripts to communicate with one another. The problem is that the usual bits that you'd use to ensure a random tempdir/tempfile name aren't really available to you across scripts. That is: 1. You might say that the control file should be kept in something like /tmp/mastercontrol_$$. But of course the commitinfo's $$ is different from the loginfo's $$, and there's no way to correlate them. 2. So you might say that the control file should be kept in something like /tmp/mastercontrol_`date run through some filter`. But obviously that's not random enough; multiple cvs commits would blow that one away. 3. You might say that the control file should be kept in something like /tmp/mastercontrol_$parent_pid_via_getppid. But commitinfo's getppid() is different from loginfo's getppid(). So the control file I don't think solves the problem as it's hamstrung by the very same thing that I'm trying to solve. :-( The hackish thing I'm leaning towards is parsing some ps -ef output, armed with getppid (in the case of loginfo). That should let me figure out what process it was that forked and execed, which would lead me back to the correct temp directory. I figure this hit in performance should be OK since the commit at this point has already happened and we're just doing something with the log message. Cheers, Laird
Re: Next CVS release? (1.10.9?)
Tony Cleveland wrote: Are there any plans of make another CVS point release to include the many fixes in the development version? Of course you can just run the development version but it would be nice to have a milestone that was designated at least some what stable. +1; CVS will get more corporate adoption that way. There's some hesitancy around here about going to 1.10.8 because it's not marked as a "stable" release. Cheers, Laird
CVS pids and the pids of its kids
Sounds like the latest Harry Potter book. Through extensive hammering and beating on cvs, I've established the following Very Likely Thing: * The ID of the cvs process that runs commitinfo and verifymsg scripts is NOT the same as the id of the CVS process that runs the loginfo scripts. * Specifically, the ID of the cvs process that runs the loginfo scripts is always 3 greater than the id of the cvs process that runs the others. Is this coincidence? Fact? I can't get that "3" number to change. Comments? Cheers, Laird
Re: CVS pids and the pids of its kids
Donald Sharp wrote: What does it matter? 1. If my commitinfo script leaves a dropping behind it in the cvs temp directory (which is of the form /tmp/cvs-serv20873 when cvs is invoked via rsh or pserver or probably gserver), and my loginfo script wants to retrieve that dropping, the loginfo script needs to know the name of the temp directory. 2. To get the name of the temp directory, the loginfo script needs to know the pid of the cvs process that ran commitinfo, because that's embedded in the temp directory name, as detailed above. 3. But the pid changes between commitinfo time and loginfo time. So I'm trying to see if it changes deterministically. more than likely cvs is just forking and execing... Doesn't a fork and exec result in...two addi...aha, but the second cvs (the one that's exec'ed) is then invoking my loginfo script so that's why loginfo getppid() returns commitinfo.getppid() + 3. Got it. Cheers, Laird
Re: CVS pids and the pids of its kids
TC wrote: He is probably tring to do some stuff with the commit loginfo scripts they hide in $TMPDIR/cvs-serv[pid] (server.c) if script he is in is calling out to get the parent process id he's not going to find the right cvs-serv[pid] dir with the contant he is expecting ... We have a winner. So is it then true in general (I am almost 100% sure that it is) that in between the commitinfo/verifymsg scripts getting executed and the loginfo script getting executed some other program in the system could come along and grab a PID, thus making the delta between the loginfo ppid and the commitinfo ppid be greater than 3? That is, the fact that I'm seeing nothing grabbing a pid inbetween the fork and exec calls doesn't mean that something COULDN'T grab a PID at that point. SO I really shouldn't rely on the delta being 3 at all, should I. Cheers, Laird
Re: [cciug] general makefile (and script) style rule
Wolfgang Laun wrote: Talking about UNIX (vanilla) Make and GNU Make, I'd say that you're in for some fun and games if you try to make this robust against spaces in path names by using some general set of rules. It would be possible to put quotes around all macro expansions where one path name is known to be expanded (as in "$(CLEARTOOL)" in your example). But what do you do with $^, for instance? For what it's worth, our toplevel makefile (actually our platform description, following "Applying RCS and SCCS" by Bolinger and Bronson) defines an acceptable quote character for the shell (on Windows you have QUOTE='; on pretty much anything POSIX you have QUOTE="). Then our (say) install targets look something like this: install : $(VARIOUS_FILES) $(INSTALL) $(foreach file,$^,$(QUOTE)$(file)$(QUOTE)) $(INSTALLDIR) The same platform description of course would cause $(INSTALL) to be, say, "copy" or "xcopy" or some such on Windows and "cp" or "install" everywhere else. GNU make v3.78. Cheers, Laird
Re: Checking branch for commit
Marc Poinot wrote: Laird Nelson wrote: Additionally, you can get the old version by having your commitinfo script look in ./CVS/Entries; the line with the filename in it will also have its old version. On the server side ? Yes; even in a pserver or rsh context. If your script is being called in a pserver or rsh context: 1. Its current directory will be something like /tmp/cvs-serv2947 2. The current directory will always have a CVS directory in it 3. The CVS directory in it will always have at least an Entries file 4. The CVS/Entries file will always have at least the lines in it representing the files that are being committed 5. As part of a standard Entries format, each line will contain the relative filename, the "old" revision, and some datestamp (whose semantics I can't recall at the moment). Here's an example: /ScopeTypes.java/1.1/Wed Jul 12 22:21:05 2000// If the revision is "0", then the file is being cvs added. If the revision is negative, e.g. "-1.3", then the file is being cvs removed. If the revision is anything else, then the file is being committed normally. Cheers, Laird
Re: questions about CVS
- Original Message - From: Adam Winter [EMAIL PROTECTED] First, how can two products share a module? Release the module as a regular product internal to your company, with regular point releases. Then treat it like any other third party product you depend on. I say this not to imply that CVS can't share modules, but to point out that it's often better done this way for maintainability reasons. Sometimes app2 can't just pick up the changes made to the module that are suitable for app1; it's nice to be able to allow individual applications to decide when and where to "upgrade" to the latest version of your module. Cheers, Laird
Re: cvs tag -F and branch tags, (was Re: Branches vs. keyword expansion)
Stephen Cameron wrote: Well, guess what... You just converted "branchtag" from being a branch tag into being a regular tag. Not only that, but now you have NO idea what revision "branchtag" used to point to, and no way to find out, so you can't even undo it. Of course this could be interpreted as a feature :-) by using it in those cases where a branch is truly dead and should never be revived. In several "flying-fish" style patterns branches are orphaned fairly frequently; I've been looking for a way to orphan them permanently (knowing full well what that entails). Cheers, Laird
Valuable *info information
I thought I'd post this here in case it proves useful to others. Here
is a random list of Things That Are True of the various *info files. It
is incomplete and in no significant order whatsoever. Version tested is
cvs 1.10 on Solaris, built from source.
1. when running in local mode, CVS runs in the actual source directory.
2. when running in rsh OR pserver mode, CVS runs in a directory named
/tmp/cvs-servXXX directory (where I assume /tmp is really $TMPDIR)
3. when running from commitinfo, args are as follows:
$CVSROOT/path/to/directory/where/file/being/committed/is
relativeFileBeingCommitted
4. when running from verifymsg, single arg is filename of log message
5. no args by default when running from loginfo
6. From taginfo documentation:
The "taginfo" file is used to control pre-tag checks.
The filter on the right is invoked with the following arguments:
$1 -- tagname
$2 -- operation "add" for tag, "mov" for tag -F, and "del" for tag
-d
$3 -- repository
$4- file revision [file revision ...] (the one being tagged)
7. Looks like you can tell if something is being cvs removed because
the relevant line in CVS/Entries looks like this:
/theFile.txt/-1.56/the date goes here//
(note the minus sign).
8. Verifymsg scripts have no way at all of determining what directory
file is in
9. Loginfo scripts always get at least one argument IF the %{}
construct is
used, even if it's %{}. Components in the %{} are space-separated,
thus screwing up Windows. Code defensively. Additionally, it is
the case that
if you put *any* character into %{} other than sVv, it will be
expanded to the empty
string followed by a comma. For example:
Filter argument: %{xxx}
First and only argument to loginfo script (in quotes): "some
directory/here ,,,"
Filter argument: %{s}
First and only argument to loginfo script (in quotes): "some
directory/here theFile.txt"
(I think I have that right). So it looks like the first "component"
of the filter argument
is always the directory within the repository where the file whose
log message is being
captured resides. Unfortunately, it is space-delimited, which
screws you up.
10. Order of invocation per file on commit is:
commitinfo (abort on failure)
verifymsg (abort on failure)
commit happens
loginfo
11. commitinfo and verifymsg run by same parent pid; not so loginfo. So
a getppid() call
will return the same PID for commitinfo and verifymsg but will be
incremented by 3 when
loginfo is run. I don't know if the "3" is reliable or
timing-based.
Cheers,
Laird
Re: New trigger system
Ian Wells wrote: I keep finding comments about the need to implement a new system of triggers which is more comprehensive and orthogonal than the current commitinfo/loginfo/taginfo one. Has there been any progress on this (code, designs, or even first thoughts) or is it still waiting for someone to spend time on it? I'm taking a slightly different approach. I'm bashing out a perl adapter of sorts that you would install as the script for each *info file, and then it would normalize the information and allow you to write common triggers that snap into *it*. Once I have it even roughly working I'll release it under the Perl Artistic License. Cheers, Laird
CVS pid available?
I'm working on an ACL framework that snaps in under the various *info files. Could someone please tell me if it is possible (without patching the CVS code) to obtain the CVS pid? I can do this when the server is being accessed via, e.g., :pserver: or :ext: or :server:--the current directory for all *info files is something like /tmp/cvsserv-3093 where 3093 is the pid. But for the local case that won't work. Also I thought I could get this via the getppid() (get parent's pid) function in C and perl, but apparently the same process does not invoke all *info subprocesses! How odd. Any comments welcome. Cheers, Laird
Re: Patches or work-arounds requested for lock problems
[EMAIL PROTECTED] wrote: Does anyone know of any pathes [sic] that will fix this problem? Well, CVS has two camps of users: 1. Those who use it because it's been designed to support concurrent development (read: no locks), and because they believe that a project where "communication" is accomplished via a software locking mechanism is doomed. 2. Those who use it because it's free, regardless of how it was designed. Ideally they'd like it to behave like all other version control systems they've seen, or at least don't really care about concurrent development (read: they like locking files). Because CVS was designed for (1) and only happens to be suitable for (2) by virtue of its price, what you're describing isn't really a problem--it's the way that CVS was designed to be used. It's interesting to note that locking is "possible" (not really) only because of two things: 1. The happenstance fact that CVS uses RCS files for storage 2. The happenstance fact that CVS was originally a bunch of scripts around RCS to (ironically) get around RCS' strict locking stuff so that it could support concurrent development and automatic merging, so it just happens to use the RCS administration system to administer the RCS files it manages 3. A perl script in the contrib directory that takes advantage of happenstance facts (1) and (2) above that simply resists checkin if the $Locker$ field is full. So cvs admin -l is actually a call into the old RCS administration system, and in fact doesn't do a damn thing as far as CVS out-of-the-box is concerned; it merely sets the $Locker$ field in the underlying RCS file. Presumably the converse, cvs admin -u, does the reverse. If you couple this little data-flipping switch with the locking script in the contrib directory--which just looks at the $Locker$ field and decides to resist checkin if there's anything there--then you get "pseudo locking", which regrettably now apparently means to folks that CVS "supports" locking. Short answer: it doesn't. Cheers, Laird
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: merging
Larry Jones wrote: Moshe Levy writes: So, how do i avoid the automated deletions in the merge ? i think the cvs should atleast warn or do a diff on that kind of a change. You don't. As far as CVS is concerned, a change is just deleting some old lines and inserting some new lines; what's so special about the case where there aren't any new lines? Not only that, but I'd hate to have my recoverable builds based on a tool that didn't track deletions! Cheers, Laird
Re: Command level access control
Tony Cleveland wrote: The taginfo script will definitely work for what I was tying to do, I had not thought of that. The only drawback is that you end up with another authorization file "taggers" that needs to be maintained. I'm actually (in my free time) working on a crappy little perl harness that you'd install in commitinfo, loginfo, taginfo, verifymsg, etc. that would normalize these various files/hooks on top of a basic access control architecture (the way it should have been done, as far as I'm concerned, in CVS to begin with, but I'm not complaining as I didn't write it). Then, for example, you'd just save one file (or stuff something in a database somewhere) saying what users can do what. Remember, in ACL systems you can either: 1. Hang an ACL off of the guy that lists what he can do to what objects 2. Hang an ACL off of the object that lists what guys can do what to him 3. Hang an ACL off of the action that lists what guys can do said action on what objects Since, in CVS, the number of objects is always growing (i.e. the files in the repository), the number of actions is (relatively :-)) constant, and the number of users is typically moderately small and managed by the OS, I'm going with approach (1) above. The only thing that comes to mind about how to implement this in a more generic sense would to modify the format of the passwd file. Fields would to have to be added that would control the different types of permissions. The main benefit of this would be a single point of administration which IMHO is a big usability point. Your suggestion here also opts for option (1), but I personally wouldn't throw this information in the passwd file. Cheers, Laird
Off topic, sort of: best ChangeLog practices?
Various posts here have been tangentially involved with ChangeLogs. Emacs has a ChangeLog mode. The free/open source communities seem to make great use of these things. What are they? Is there some URL or other source of information that someone can point me to on what a ChangeLog is, best practices on what it should look like, best practices on when it's edited, what it's used for, etc.? I feel like I'm missing something fairly important at a high level when I ask: what does a ChangeLog give you that $Log$ messages do not? We now return you to your regularly scheduled cvs discussion. Cheers, Laird
Re: Interest in checkoutinfo administration file?
Erik Kluzek wrote: Is there any interest in CVS having a "checkoutinfo" administration file? Yes, yes, yes, yes, yes. I've read the other messages in this thread and am not convinced that the modules file -o option will do what I want in all cases. I've found several cases where I'd like to be able to hang functionality off a checkout. Cheers, Laird
Re: Selection of branches for commit
t
works in client/server setups. Bcvs_mainline_protector will use
this variable if found; otherwise it will fall back to using IUSER
and then ILOGNAME.
=item IUSER
Bcvs_mainline_protector will consult this variable only if
ICVS_USER is not set.
=item ILOGNAME
Bcvs_mainline_protector will consult this variable only if
ICVS_USER is not set.
=back
=head1 FILES
=over 4
=item F/path/to/cvsroot/CVSROOT/mainline
Fpath/to/cvsroot/CVSROOT/mainline is a file containing one cvs
username per line. If this file exists at all, empty or not, then
Bcvs_mainline_protector makes the assumption that the main branch is
sacred, and without any other information will not allow modification
to it. If this file exists and contains one cvs(1) username per line,
then only those usernames will be able to modify the main branch. A
sample excerpt of this file follows, showing that Cjbloggs and
Cltorvalds are the only usernames permitted to modify the main
branch of any project in this repository:
jbloggs
ltorvalds
You'll want to edit FCVSROOT/checkoutlist to include Fmainline so that it is
automatically checked out into the FCVSROOT after it is modified.
=back
=head1 DIAGNOSTICS
Bcvs_mainline_protector outputs any messages or errors prefixed with
three asterisks and a space ("*** ").
=head1 EXIT STATUS
=over 4
=item 0
Bcvs_mainline_protector exited normally.
=item 0
Bcvs_mainline_protector encountered an error of some kind. Any
commit in process was not executed.
=back
=head1 AUTHOR
Laird Nelson [EMAIL PROTECTED]
=head1 BUGS
To report a bug, please send email to the author.
=head1 NOTES
Note that upon installation of Bcvs_mainline_protector as a
Fcommitinfo script, the F/path/to/cvsroot/CVSROOT/mainline file
(see L"FILES") must contain at least one username if it is to be
subsequently modified! If this does not happen, then no one will be
able to modify any main branches in the repository until this program
is disabled.
=head1 SEE ALSO
Lperl(1), Lcvs(1), http://www.loria.fr/~molli/cvs/doc/cvs_18.html#SEC162
=head1 HISTORY
$Log: cvs_mainline_protector,v $
Revision 1.1 1999/12/02 15:58:25 lnelson
Initial revisions in this repository; moved from private repository.
Revision 1.3 1999/08/13 19:18:09 lnelson
Improved mail handling somewhat.
Revision 1.2 1999/08/13 17:56:46 lnelson
Documentation update.
Revision 1.1 1999/08/13 17:52:53 lnelson
Initial revision.
=head1 COPYRIGHT
Copyright 1999 Laird Nelson [EMAIL PROTECTED]. All rights
reserved. This program is free software; you can redistribute it
and/or modify it under the same terms as Perl itself.
=cut
Re: patch for CVSUSER env variable
Ingolf Koch wrote: It appears that when using pserver together with a CVSROOT/passwd file which maps cvs users to different UNIX user ids (i.e. with three entries per line), it is not possible by programs called e.g. on commit automatically to find out which _cvs_ user did the commit. Wrong; in the commitinfo script you can write a line that looks like this (for example): DEFAULT yourProgram $USER ...(can't remember whether the "match everything" rule is DEFAULT or ALL; immaterial to this point.) "$USER" here is not an environment variable but is the cvs server's notion of the USER, i.e. the _cvs_ user you refer to above. The $USER environment variable is set to the _other_ user, in case you need to see that. The patch is not needed. However, for programs that cannot accept command line inputs (not sure what those programs might be, then your patch might be useful. Cheers, Laird
Re: bin directory
Larry Jones wrote: Since Unix doesn't distinguish between text and binary files, it is safe to import binary files on Unix without marking them as binary. ?? I thought marking a file as binary (during add *or* via cvs admin) simply turned off keyword expansion. What else do Micro$oft "systems" do that is different from this? (The way your response is worded makes it sound like although cvs add -kb file should have the same behavior on both platforms, viz. turning off keyword expansion, Micro$oft "systems" require you to cvs add -kb up front or else something cannot be fixed later. Why should this be true?) Cheers, Laird
Re: bin directory
Larry Jones wrote:
They convert between the external end-of-line characters (CRLF) and
the internal end-of-line character ('\n'), and they also interpret ^Z
(SUB) as end-of-file when reading (they may or may not write ^Z at
end-of-file when writing). Both of these can cause serious data loss
when applied to binary files.
Thanks, I actually knew this part--I guess the answer I'm looking for is
hidden in this: if you don't add a binary file on a Micro$oft "system"
as a binary file then it is at least possible that no amount of cvs
admin -kb'ing the file after the fact will help; the data may already be
lost.
Right?
Cheers,
Laird
Re: tag date/time
Ofer Nave wrote: Is it possible to figure out the exact time a tag was applied to a project in cvs? (I parsed through a ,v file but didn't see a way to glean this information.) Isn't this what cvs history is for? Granted, it does not store this information in the ,v file, but it's available, IIRC. Cheers, Laird
Very minor feature request
Suppose there are two sandboxes in the world: mine, and someone else's. We both access the same CVS repository. If The Other Guy removes fileA from his sandbox, then when I do a cvs update in mine, I get a message that says something like: warning: fileA is no longer relevant ...and fileA disappears, as it should. Wouldn't it be nice if the log message given as the reason for removal were displayed as part of the warning message above? E.g.: warning: fileA is no longer relevant (Renamed to fileC) Since removals are most often done to effect a rename operation, that would help sandbox updaters to figure out why fileA disappeared. Thoughts? Cheers, Laird
Re: Access to CVSROOT/passwd mapped username
Rodent of Unusual Size wrote:
The Perl CVSROOT/foo script, however, shows different values for
$ARGV[0] (the $USER above) and $ENV{"USER"} (the actual environment).
The former is the remote (client) username I want, whilst the
latter is the local (server) username.
It looks as though whatever does the expansion of $USER is using
an internal table, not the environment, since the admin-file
expansion of $USER differs from the value in the environment table.
You are correct.
Internal variables are described in the Cederqvist.
Cheers,
Laird
Re: MKS/SI and CVS
"David L. Martin" wrote: MKS Source Integrity is *based* on RCS, but it isn't 100% true blue RCS This has been our experience as well. However, if you *can* get an MKS archive into CVS, do so; CVS is MUCH better than MKS. Cheers, Laird
Importing of CVS sources question
I started by importing cvs v1.10 lo these many months ago into our own CVS repository. Now I pulled down CVS v1.10.8 and imported that onto the vendor branch following the recommended steps. Everything worked fine. Then I went to make it. On making lib/getdate.c, it looks like that's made from lib/getdate.y. During make, therefore, it tried to overwrite the existing checked-in copy of getdate.c, and asked me if I wanted to override the protection on getdate.c. I understand why it's doing this. However, it strikes me that getdate.c is a generated file (after all it's made from some combination of its previous self and a yacc file). If it's a generated file, why isn't there an entry for it in lib/.cvsignore in the distribution? Should I check in the "made" copy of getdate.c or the getdate.c that existed before I ran make? Cheers, Laird
$USER etc. variables (NOT env. variables)
I know through rumor (and testing) that, e.g., in a commitinfo line you can say something like this: ALL /some/program $USER ...i.e. you can put what looks like a shell environment variable substitution in the line and cvs--I believe, i.e. not the shell--will expand it for you. (I also know that some of the other admin. files have different ways of getting, e.g., the user--notify, for example, uses "%s" but probably should have been specified to use $USER like commitinfo.) I have three questions. 1. Where (other than the source; I'm hoping I don't have to get out my shovel and start digging) are these pseudo-environment variables documented? 2. If they are not documented anywhere (I can't find them in the Cederqvist), then could someone send me a list of them? 3. What "user" is $USER expanded to in a pserver context? The mapped-to user on the server side, or the "unmapped" user? Cheers, Laird
Build systems
My curiosity is piqued by several posts recently on the subject of builds. (I preface this by saying that I am fully aware that cvs is not a build tool, nor does it enforce policy, nor does it do my taxes (regrettably), etc. etc. etc. etc. etc. etc. ad nauseam as we have all seen in the 34734983 messages per day that deal with the subject. :-)) For those of you that do run builds of your products/systems where cvs is the underlying version control system, how many of you: 1. Run them (let's say nightly or frequently at any rate) out of a sandbox that has been massaged until there are no modified or ? files in it 2. Run them using make and VPATH such that the build takes place in directory tree B, but the source is looked up via make's VPATH mechanism from directory tree A (which B mirrors in structure), where A has been massaged until there are no modified or ? files in it 3. Do (2) but do a cvs -export to a fresh area first We do not do (1) because building in your source area is a bad idea if you want to support many platforms. This practice is explained and recommended in O'Reilly's excellent "Applying RCS and SCCS". We currently do (2) using a homegrown build system modeled after TCCS as outlined in the O'Reilly book (the homegrown system basically implements TCCS in perl using cvs as the underying VC system; complete with the robust parallel make tool). This allows us incremental builds (i.e. we don't have to do a full export every time we want to run a simple build). We do NOT do (3) because we can get the same results with (2), although the build tools have to be more careful to make sure there are no "M" or "C" or "A" or "?" lines after an update. My gut hunch is that people do mostly a combination of (1) and (3). I'm trying to figure out whether (3) is an option we should move towards. Cheers, Laird
