Re: Blinded by philosophy (kinda long)
Kate Ebneter wrote: > Please, really, I'd really like to know why, if you want to do > serialized synchronized development using locking, you chose CVS in the > first place? I actually have been staying out of this for a while but thought I'd offer what I hope is a common viewpoint. CVS at some point became accidentally quite good at being a platform independent client-server version control system, whether you would ideally like to develop concurrently or not. Many people choose CVS on the basis of the fact that (a) there are clients for every platform (see jCVS, for example; Win/MacCVS, TkCVS, command line for at least three platforms that I know of), (b) the model supports simple distributed development (after all there is no one workspace that is "more official" than any other; contrast this with MKS and its derivatives) and (c) (obviously) the price and the flexibility are right. For such people, the fact that CVS was designed to handle a particular style of development, viz. concurrent development, is something that simply may not be of interest. These people will note that CVS doesn't have locks, will sigh somewhat, weigh the pros and cons of a client/server VC system that's RCS-compliant for free but that has a particular development methodology in mind, and will come out in favor of using it. These people are typically working in a shop or on a project that has mixed Unix and NT machines, with some Linux thrown in for good measure, and maybe an HP machine or two. Typically when people select a VC system, they do so at the outset of a project, which means they think that the project will stay small (they're usually wrong) and hence something like ClearCase or any of the other heavies is way too expensive. They consequently look around for a VC system that will let developers working on all the platforms mentioned (and possibly working at home on unsupported machines) access the VC repository in a simple, cheap manner. They don't care up front whether the system really has locks or not; it probably doesn't even occur to them. To illustrate, this whole debate would probably go away if someone took, say, RCS, bolted on or somehow made it accessible via a client/server protocol, and offered it up for free on a zillion platforms. The herd of folks who don't want concurrency but who do like the platform-independence and client-serverhood :-) of CVS today would stampede to such a product, and the herd of folks who want concurrency but don't really care about, say, the pserver side of things would stay contentedly put. Hope that helps answer your question. Cheers, Laird
cvs tag vs. rtag
Can someone give me a pointer on when to use cvs tag vs. when to use cvs rtag? I know, for example, that cvs tag doesn't show up in the history file, and that cvs rtag requires you? I think? to feed it the revision number of whatever you're tagging, thus preventing you from saying "cvs rtag the tree the way it is now". What common situations is each command used in? 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
val-tags
Could someone please kindly point me to the spot in the Cederqvist where the val-tags file is mentioned? I can't find it and I don't know what it is. 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
Change in -d option in 1.10.8 (from 1.10)?
I read this in the 1.10.8 NEWS file: * The -d command line option no longer updates the CVS/Root file. For one thing, the CVS 1.9/1.10 behavior never had updated CVS/Root in subdirectories, and for another, it didn't seem that popular in general. So this change restores the CVS 1.8 behavior (which is also the CVS 1.9/1.10 behavior if the environment variable CVS_IGNORE_REMOTE_ROOT is set; with this change, CVS_IGNORE_REMOTE_ROOT no longer has any effect). I'm not sure I understand quite what's going on here. We're currently running 1.10; I'm looking to move us up to 1.10.8 sometime, and am doing some preparatory research. I'm concerned (probably unduly) that something here will cause normal practices around here to break. We use the -d command line option a lot because there are several CVS roots in house. For example, if I'm working on projectX, I might have a working directory structure like this: /home/lnelson/projects/projectX ...where projects is just a "normal" directory. I cd into projects and do cvs checkouts like this: % cd $HOME/projects % cvs -d:pserver:[EMAIL PROTECTED]:/the/projectX/cvsroot checkout projectX ...then sit back while cvs churns. From that point forward I can go into projectX and do updates and so forth without using the -d option. I assume I can still do this, yes? (Am I to understand that 1.10's behavior was something like this: if I'm in my projectX working directory and someone moves the CVS root on the server out from under me I can do a cvs -d in my working directory and the intent was to have cvs update my project's Root files so that the new cvs root is found? If that's what's going on, that's cool; we never made use of this feature anyhow.) 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
Re: Bill Of Materilas (BOM) +script ?
B-CK ANDREAS/TKELOV96ORD wrote: > > Is there any ready done script or function for CVS > that produces a list of all files with a certain label, BOM Not that I know of. Usually BOMs are only good for distributing with installations (they are also known as manifests). Consequently I put the BOM-generation work into my build tools, not into CVS scripts. I have written a BSD install replacement that appends to a file; then I make sure that in my makefiles I never do this: $(INSTALL) * $(INSTALLDIR) ...but do this instead: $(INSTALL) $(FILES) $(INSTALLDIR) Then my install script appends to a BOM that finally gets copied into the install directory and that's it. 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
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: 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: Very minor feature request (fwd)
Ofer Nave wrote:
> Whenever I notice something interesting in my update logs, I hop over to
> cvsweb and check out the comments, and sometimes even the diff.
No, no, I understand I *can* do that, I'm just suggesting that in the
case of a removal a cvs update should show the log message, since log
messages are particularly important for removals.
{shrug} No big deal either way; it's easy enough to patch.
Cheers,
Laird
Re: bin directory
Larry Jones wrote:
> They convert between the external end-of-line characters () and
> the internal end-of-line character ('\n'), and they also interpret ^Z
> () 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: 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: 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
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
":pserver:$user\@$hostname:$ENV{'CVSROOT'}";
&send_email(<mail($from);
$smtp->to($opts{"email"});
$smtp->data();
$smtp->datasend("To: $opts{'email'}\n");
if ($opts{'replyto'}) {
$smtp->datasend("Reply-to: $opts{'replyto'}\n");
}
$smtp->datasend("Subject: $subject\n\n");
$smtp->datasend(@_);
$smtp->dataend();
$smtp->quit();
};
if ($@) {
warn "*** $@";
}
}
1;
__END__
# Pod follows.
=head1 NAME
cvs_mainline_protector - protect a cvs repository mainline from modification
=head1 SYNOPSIS
# Line in commitinfo file:
ALL /path/to/cvs_mainline_protector [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
--smtphost=mail.yourorg.com
=head1 DESCRIPTION
B is a program designed to be run as a cvs(1)
F script. It protects the main branch of any project from
unauthorized modification.
B consults an access list named F in
the F directory of the project. If the user who is trying to
commit a file is not listed in this file, then he or she will not be
allowed to commit his or her changes. B On initial
installation, F must contain at a minimum the username of
the person who will modify the F file itself!
You'll want to edit F to include F so
that it is automatically checked out into the F after it is
modified.
=head1 OPTIONS
B takes two options.
=over 4
=item B<--email=ADDRESS>
Optional. If this option is specified, then email will be sent to
B informing the recipient of any unauthorized attempts to
modify the mainline of any module in the cvs repository. If not
specified, then no email will be sent.
=item B<--smtphost=HOSTNAME>
Optional. The name of the SMTP host via which mail will be sent. If
this option is not specified, then the current hostname will be used.
=item B<--replyto=ADDRESS>
Optional. Valid only if B<--email=ADDRESS> is specified. If
specified, this option should indicate what email address should be
used for the C header in any email messages sent out by
B.
=item B<--fromaddress=ADDRESS>
Optional. Useful if B<--email=ADDRESS> is specified. Specifies the
user actually sending email. Your sendmail configuration will
determine what this string should be; generally it is
C<[EMAIL PROTECTED]>. If omitted, then the current username and the
current hostname are used, which are not always what you want.
=back
=head1 OPERANDS
cvs(1) documentation indicates that F scripts are invoked
with the path to the cvs(1) repository as their first operand, and the
names of any files being committed as subsequent operands.
=head1 EXAMPLES
Your F should contain a line like this:
# Line in commitinfo file:
ALL /path/to/cvs_mainline_protector [EMAIL PROTECTED]
[EMAIL PROTECTED]
It's best to place the email address of your configuration management
guru as the argument to the B<--email> option (see L<"OPTIONS">) if
you wish email to be sent. Of course, I or I may not want
email to be sent, but then he or she is probably setting this program
up in the first place. C<:-)>
=head1 REQUIRED PERL MODULES
strict
English
File::Basename
Cwd
Sys::Hostname
Net::SMTP
Getopt::Long
=head1 ENVIRONMENT
B relies on several environment variables
being set by cvs(1) as documented in its reference manual
(http://www.loria.fr/~molli/cvs/doc/cvs_19.html#SEC174).
=over 4
=item I
cvs(1) documents that F scripts are invoked with
I set to the full path to the repository.
B uses this to look up the F access
control list (see L<"FILES">).
=item I
Some patched versions of cvs(1) set this environment variable. It is
preferred over the more commonly set I variable, because it
works in client/server setups. B will use
this variable if found; otherwise it will fall back to using I
and then I.
=item I
B will consult this variable only if
I is not set.
=item I
B will consult this variable only if
I is not set.
=back
=head1 FILES
=over 4
=item F
F is a file containing one cvs
username per line. If this file exists at all, empty or not, then
B 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 C and
C are the only usernames permitted to modify the main
branch of any project in this repository:
jbloggs
ltorvalds
You'll want to edit F to include F so that it is
automatically checked out into the F after it is modified.
=back
=head1 DIAGNOSTICS
B outputs any messages or errors prefixed with
three asterisks and a space ("*** ").
=head1 EXIT STATUS
=over 4
=i
Truncated files in CVS?
Has anyone noticed ANY circumstances in which CVS, running in client-server mode, will truncate a file on the server side, on a block boundary? I have a user who is claiming that CVS truncated an Excel spreadsheet that he checked into the repository. He added it correctly, with the -kb option (which I assume sets the merge methodology (effectively) to COPY instead of MERGE?), but discovered that the file (when he checked it out again) was considerably shorter. I cannot duplicate the problem. Cheers, Laird
Re: help with triggers
Mike Shamberger wrote: > > Hi, > > How does CVS implement triggers? I couldn't find anything in > the cederquist manual about triggers. I want to prevent labeling > of files on the release branch by developers. Are triggers implemented > by a shell script wrapper to the cvs command? Can someone send me > an example of some triggers? > > Thanks, > Mike See http://www.loria.fr/~molli/cvs/doc/cvs_18.html#SEC160 and following. Programs can be fired at certain steps in the checkin or modification process; generally updates, exports and checkouts proceed without possibility of intervention. A commitinfo script returning false will cancel a commit. I believe the same is true of a taginfo script, although I could be wrong. 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: 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
Re: Get a list of users that checked out files
Veronica Lee wrote: > Is there a way in UNIX or WinCVS to get a list of users that have > checked out files but have not checked them in? We need this function > for release management. CVS uses the term "checkout" in the ways that other version control systems use the term "fetch" or "create sandbox" or something like that. CVS has no real concept of checking out a file, i.e. reserving it for edit. You can cvs edit a file, which communicates briefly with the repository to notify anyone who wants to be notified that you're "checking out" the file, but this is not required. Consequently, what you want is not easily accomplished, if it's possible at all. If everyone in your organization were to have their environment variable CVSREAD set to true, and if everyone in your organization were to cvs edit files before changing/committing them (as opposed to simply making them writeable and then making changes), then it's possible you could hook up something to the watch/notify mechanisms (http://www.loria.fr/~molli/cvs/doc/cvs_10.html#SEC83 and, specifically, http://www.loria.fr/~molli/cvs/doc/cvs_10.html#SEC85). The "notify" file can be consulted in these cases when a cvs edit is applied. Not quite what you want, but probably as close as you're going to get. :-) Cheers, Laird
Re: Should not check in after running CVS release command
Stephen Rasku wrote: > I tend to use release just to determine if I have any modified files > that I should check in. cvs -n -q update also works well for this (i.e. don't really update, but tell me what you would, and do it quietly). Cheers, Laird
cvs editors information lost?
Under what circumstances will cvs editors not return anything when it should? I've got a case where someone has definitely cvs edit'ed a file. When I do a cvs editors on that file in *my* sandbox, I do not get the anticipated information telling me that indeed this other user is currently editing the file. Are there known situations in which this happens? Or is this a new bug I should formally write up? 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: 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
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
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)
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
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
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: Checking branch for commit
Marc Poinot wrote: > The effect is that you can retrieve the old revision, the (possible) tag > and the type of the file as an arg of the commitinfo called script. For tagging operations, you can always write a taginfo script instead. 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. So no patches really needed. :-) 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: [cciug] general makefile (and script) style rule
Wolfgang Laun wrote: > Nice, but how do you set VARIOUS_FILES when your file names have > embedded spaces? Yeah, this is a problem you can't get around without intervention. 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: 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: CVS pids and the pids of its kids
- Original Message - From: Eric Siegerman <[EMAIL PROTECTED]> > Why not make the original cvs (pid 1000 in my example) export the > temp-dir name into an environment variable? The variable would > be scoped correctly, by definition. And there would be no > reliance on PIDs. I'd like that. One of my design goals however is to avoid patching cvs. So if and when cvs gets an official release where that behavior is incorporated, I'll cheer loudly. Of course if cvs moves to a different tempdir algorithm, as you note, then this export becomes rather pointless. All of this, of course, is to let the various *info scripts communicate with each other; this problem would go away with a completely revised trigger mechanism. 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-nserver and latest CVS advisory (Was: patch to make CVS chroot)
Mike Castle wrote: > > On Wed, Aug 09, 2000 at 11:54:33AM -0400, Justin Wells wrote: > > Is it as easy for a WinCVS user to set up ssh as it is to set up pserver? > > Yes. Excellent! I've been looking to do this for a long time. Could you point me to the URL that says how to do this? I followed the guides at SourceForge and they suck rocks. 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: 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
Bug? in update behavior
Suppose I do this: cvs co -P -r SOME_TAG some_module ...then obviously some_module has the sticky tag SOME_TAG applied to it throughout. Fine. Now suppose I cd somewhere into its guts and update a file to a different sticky tag. If I then do a cvs update in that directory (or anywhere above it, for that matter) everything works like you'd assume: the files tagged with SOME_TAG don't change, and the file I just updated to its other sticky tag retains it. But if I update that file to a revision which has state "dead", thus causing CVS to remove it from the directory, then when I do a cvs update in that directory, instead of recognizing that I've updated that file to a sticky tag (i.e. the tag identifying a dead revision), CVS brings back the previous revision of the file (the one tagged with SOME_TAG). So here's an illustration: cvs co -P -r SOME_TAG some_module ...time passes... cd some_module/into/its/guts cvs update -r NEWER_TAG file_present_but_will_be_killed cvs server: warning: file_present_but_will_be_killed is (no longer) pertinent cvs -q update U file_present_but_will_be_killed cvs status -v file_present_but_will_be_killed ...status information showing file_present_but_will_be_killed's sticky tag to be SOME_TAG, not NEWER_TAG Is this desired functionality? cvs 1.10 on Solaris 2.7. 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: 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: 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: Unidentified subject!
Ken Riley wrote: > > Is it possible to have different permissions on different branches within > the same module? For the beginnings of this, see my nascent cvssupport project on SourceForge (https://sourceforge.net/projects/cvssupport/). The existing script checked in there lets you protect the mainline; future versions (almost ready for checkin) allow you to set permissions (using the regular *info files) on revision-, person- and action-based bases. 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: Security Problems with CVS?
Noel L Yap wrote: > > If you run ssh-agent on your side, you should be able to get away with entering > your passphrase only once. Right, which apparently doesn't? does? (certainly doesn't for me) work for Windows, because someone hasn't effectively ported it or something. It's all rather confusing, and I don't like Windows anyhow. :-) Is there a good place I can go to read up on how to use ssh in general? Everything I've ever seen is piecemeal, i.e. assumes that I already know what ssh-agent is or what it's good for. :-) Unfortunately I'm deeply, profoundly ignorant. :-) 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: 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:
^whackme.txt$
^2\.\d+$
normal-users
add
modify
remove
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: CVS versus MKS (or should I avoid moving to MKS?)
Noel L Yap wrote: > > You can use CygWin (http://sources.redhat.com/cygwin/), instead. IMHO, CygWin > provides better Unix-on-NT support than MKS does. I think he's talking about MKS Source Integrity, which is one of the most wretched, awful, kludged, hideous evil source code control systems to ever walk the planet. Of course it shines when compared to Visual Source Safe, which is what MKS feeds on when it's hungry. :-) I think *you're* talking about MKS Toolkit, which is inferior to cygwin, as you state. But fortunately it's not as ugly as its source code control cousin. Cheerfully opinionated, Laird
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-serv 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: 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
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: 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=peng>Tue Oct 3 20:50:08 2000
>GMT+isip207.isip.msstate.edu+/isip/d207/peng/tools/class/shell/Sdb;_watchers=peng>tedit+tunedit+tcommit
Looks like the format is:
_=;_=
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: 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: Repository know who has checkouts?
- Original Message - From: "Derek R. Price" <[EMAIL PROTECTED]> > The example is three > teams at the same company sharing a CVS repository. Two use 'cvs watch' by > default and one does not. So how about making it part of the modules file? Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: versions
"Hanser, Kevin" wrote: > how can I change that so it increments a different value? like version > 1.1.2 or something? This is a FAQ, although as far as I know there isn't a good FAQ answer list out there. You want to use tags instead. The revision number should be regarded as an opaque identifier for cvs only. Presumably you want to assign a label (call it a revision number if you like) to your files so you can get them back again. You do this via the cvs tag command (cvs --help tag for help; http://www.cvshome.org/docs/manual/cvs_4.html#SEC48 for details). Cheers, Laird ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS_USER
- Original Message -
From: "Jim Kingdon" <[EMAIL PROTECTED]>
> CGI uses environment variables to pass things to the scripts, and I
> guess I don't really see a problem with using environment variables.
> Although they seem to be non-portable, they aren't, really. NT and
> VMS have them (or something which the libraries make look the same to
> the programs), for example.
Yes, and then people don't have to remember what arguments to add to
their commitinfo files ("was it the *commitinfo* script that gets the
CVSROOT as the first implicit argument and then the filenames, or was
that the taginfo script? Damn, where's the Cederqvist?"). CGI IMHO is
a good analogy here; no matter how well specified the types of arguments
are (i.e. whether it's $USER or %u) I'd rather just have all that stuff
show up in the environment for me to use if I see fit. Then I just have
to memorize a few environment variables instead of remembering
arguments, their order and their quote characters across the various
*info files.
> The main kludginess associated with having CVS process the shell
> commands is that it is unexpected - people don't easily remember just
> what substitutions CVS makes or does not make. And it is one of those
> things where you get into quoting hell, where CVS does its processing,
> the shell does its, perl/awk/sed/etc (if you call them next) does its,
> and so on. It is worse with "$" than "%", though. I really regret
> that $USER hack I put in (it seemed like a good idea at the time :-)).
Yes, exactly. +1 and all that. :-)
> Furthermore, last time this came up, everyone seemed to like the
> CVS_USER patch. Or so is my recollection. I'm a little surprised no
> one (except you, Derek) is saying anything this time. Should I be
> asking on devel-cvs?
{loud noises, horns, etc.} That's one of the few patches we've actually
applied.
Incidentally, look at http://sourceforge.net/projects/cvssupport/ which
solves this problem by making it easy to write perl objects that handle
the {commit,log,tag}info processing in a consistent manner. A plugin,
no matter whether it was fired by commitinfo or verifymsg or loginfo
(and they all take different arguments in different orders) looks the
same and has access to the same information. To enable this behavior,
the launcher/wrapper program is REALLY complicated, relying on some
Entries file parsing to fill in the blanks.
While we're on the subject, any environment variable that would allow
access to the new revision number PRIOR to the commit taking place would
be wonderful.
Cheers,
Laird
___
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: 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
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: 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
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: access rights to branches
"Derek R. Price" wrote: > > Laird Nelson wrote: > > > 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. > > This isn't strictly true. The first commit of a file to a branch could go > from 1.X to 1.X.Y.1. Quite right, and, I might add, there's no workaround. :-( 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
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 2>&1 "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: 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
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: 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 /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: checking out a file (not a module)
ari gold wrote: > the best solution i found was 'cvs update -d '.. 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: 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 /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: 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: 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: 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=foo&filespec=a%7c1.2%7c1.3%7cOLD_TAG&filespec=b%7c1.1%7c1.2%7cOLD_TAG&cvsroot=wherever
Running this through a standard URL unescaper (perl -MCGI -e 'print
unescape("dir=foo&filespec=a%7c1.2%7c1.3%7cOLD_TAG&filespec=b%7c1.1%7c1.2%7cOLD_TAG&cvsroot=wherever");')
yields:
dir=foo&filespec=a|1.2|1.3|OLD_TAG&filespec=b|1.1|1.2|OLD_TAG&cvsroot=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 |||
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: 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
