CVS For VMS
Am I correct in thinking that the CVS Server has not been ported to OpenVMS yet? If so, does anyone know of a similar product, free or otherwise, that will do the same job (excluding CMS). Thanks, Robert. Robert Atkinson I.T. RD The Book Service Ltd DDI: 01206 255758 ** N O T I C E * This information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete all copies of the message. This footnote also confirms that this email message has been swept for the presence of computer viruses, however we cannot guarantee that this message is free from such problems. ** ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Branch Merge strategies
Paul Sander wrote: Brad Appleton is collecting articles documenting best SCM practices. Take a look at this URL: http://www.enteract.com/~bradapp/acme/ Yes, and they are really readworthy. Additionally, there's a mailing list about the patterns Brad describes on the ACME web site: scm-patterns. I started a thread there a week ago (and actually on this cvs list, too): "Codeline organization (branches) for medium/big projects" While I got answers or at least started a discussion on the scm mailing list, unfortunatley people on this cvs mailing list didn't jump on the thread. Basically, posters from the scm mailing list advised me to not use CVS, but other CM systems, because CVS (apparently) lacks a good merge command, while it is supporting branching very well. If someone comes up with a solution to the original problem using CVS, I would be very grateful, if she could share it with the whole list. I also will post a solution, should I see one. Regards, - Jakob ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Tools to generate report from logs?
Morning ...
Does anyone know of, or have, a script that can be run that will
generate a report of log messages since a 'tag' was set? Even something
that would trim it down to an editable list would be great ...
Thanks ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multi-user working directories
Thank you. Yes I do know about branches and merging branches. How does this solve my problem? I need to create a set of binaries from our GA branch. The GA branch has been checked out and built previously (the "Official Release" files). The question is how do I have any person (one of our Level 3 staff) be able to update the "official release" set of working files with the updates everyone has been working on and then do the build. UNIX (or in our case USS on MVS) will allow multiple people write access to these files, but CVS (specifically pserver) will not. Alex Holst [EMAIL PROTECTED] on 01/08/2001 08:56:48 PM To: Wayne Johnson/MINN/Candle@Candle cc: Subject: Re: Multi-user working directories Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): We do have procedures for having people develop the fixes on private working files. It's when they get to the point of releasing this fix we need to have one set of official code that goes to the customer. This official code should be extracted from CVS. You may want to look at the feature of CVS known as branches. It allows you to run parallel developments, and merge code back into the main tree if this is required. I strongly urge you to not use multi-user working directories, as CVS was created to get around this very problem. If you take the time to explain the situation on the mailing list, I know many can advise you on a better way than working around the powers of CVS. -- I prefer the dark of the night, after midnight and before four-thirty, when it's more bare, more hollow. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS For VMS
"Atkinson, Robert" wrote: Am I correct in thinking that the CVS Server has not been ported to OpenVMS yet? If so, does anyone know of a similar product, free or otherwise, that will do the same job (excluding CMS). Don't know. There's a binary that does at least client stuff and some other tools at ftp://ftp.cvshome.org/pub/vms/ . Nobody's contributed a binary for OpenVMS since 1.9.27, so if you need anything more recent you'll probably have to do some porting work yourself. That may or may not be a big deal. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- It seems that destiny has taken a hand. - Humphrey Bogart as Rick, _Casablanca_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multi-user working directories
Forgive me, I seem to be having problems communication the problem. Yes, I have read the manual, thank you. I've used CVS for 5 years. I did a port of CVS to MVS. I am well aware of it's capabilities. My question is how does an arbitrary user do an update to a common set of code that has already been checked out. Yes, we can have branches, and we can merge the branch deltas into each other or the trunk. After this occurs, someone needs to be able to check the code out and build it for distribution. The problem here is that we can't check it out every time we want to re-release the code. There are thousands of modules that would need to be re-compiled. We need to update the code that was already checked out and run make to build the updated modules. We then will distribute the changed executables. The problem is there could be any of several people who need to do this. I guess this may be a paradigm difference between the way mainframe code is developed and the way distributed system (spell that UNIX) code is developed. I can't believe that no one has ever run into this situation. "Derek R. Price" [EMAIL PROTECTED] on 01/09/2001 09:44:56 AM To: Wayne Johnson/MINN/Candle@Candle cc: Alex Holst [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Multi-user working directories [EMAIL PROTECTED] wrote: Thank you. Yes I do know about branches and merging branches. How does this solve my problem? I need to create a set of binaries from our GA branch. The GA branch has been checked out and built previously (the "Official Release" files). The question is how do I have any person (one of our Level 3 staff) be able to update the "official release" set of working files with the updates everyone has been working on and then do the build. UNIX (or in our case USS on MVS) will allow multiple people write access to these files, but CVS (specifically pserver) will not. Sure it will. You might want to review the Cederqvist (CVS manual), especially the sections on setting up a CVS server and "Branching and Merging": http://cvshome.org/docs/manual/cvs.html . Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not defame New Orleans. I will not defame New Orleans. I will not defame New Orleans... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: branch updates from mainline ?
Ken Versteeg wrote: on the branch, you can do: cvs update -j HEAD This will do what you want to do. The first time, but you'll really want start end tags to get repeated merges right. Review the "Branching Merging" sections of the Cederqvist: http://cvshome.org/docs/manual/cvs.html . Merging the same section of code twice will often be handled properly with a message like, "Changes between X Y are already contained in Z", but doing it too much (building up a lot of code to repeatedly remerge) may eventually strain the merging algorithm, leaving you to resolve the same conflicts every time you merge. Some of the best practices papers web pages people have been talking about on the list recently might give you some more hints. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Confucius say, "Man who live in glass house dress in basement." ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multi-user working directories
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): Thank you. Yes I do know about branches and merging branches. How does this solve my problem? I need to create a set of binaries from our GA branch. The GA branch has been checked out and built previously (the "Official Release" files). The question is how do I have any person (one of our Level 3 staff) be able to update the "official release" set of working files with the updates everyone has been working on and then do the build. Your 'binaries' statement confused me for a moment. I will assume we are not actually dealing with binary files, but text files of some sort, that CVS understands how to handle in an acceptable manner. _I_ would checkout the 'Official release', possibly make whatever changes and tag them with a meaningful name. Then I would tell others which tag to checkout and commit to. The release could be tagged according to the deadline, eg FEB12_2001. OpenBSD does this. They have a tag named OPENBSD_2_8 to which they apply critical fixes for OpenBSD 2.8. This is a live tag that changes, so all administrators have to do is checkout that particular tag to get the stable release. The code that is shipped on the CD is tagged OPENBSD_2_8_BASE. UNIX (or in our case USS on MVS) will allow multiple people write access to these files, but CVS (specifically pserver) will not. CVS has no concept of access control lists. This would be implemented through filesystem permissions. Ensure the people who need to commit changes to a directory has sufficient rights. Once you solve this problem, you can apply your knowledge of branches to the problem. -- I prefer the dark of the night, after midnight and before four-thirty, when it's more bare, more hollow. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multi-user working directories
[EMAIL PROTECTED] wrote: The problem here is that we can't check it out every time we want to re-release the code. There are thousands of modules that would need to be re-compiled. We need to update the code that was already checked out and run make to build the updated modules. We then will distribute the changed executables. The problem is there could be any of several people who need to do this. If you don't want each person who may have to do it to check out a single "build space" once which they then reuse each time they need to rebuild, I'd probably go with a shared account or group access to your shared build space. I usually prefer to avoid the shared account, myself, for security reasons. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not barf unless I'm sick. I will not barf unless I'm sick. I will not barf unless I'm sick... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Restoring a branch name
"James A. N. Stauffer" wrote: A branch name was inadvertently deleted (but the branch itself seems to be okay.) Is it possible to restore the name? Yeah, but with a large repository it'll be a lot of work. You'll basically have to retag each file individually using the numeric revision of the branch origin (maybe with 'cvs admin -n'). If you tagged your branch origin you might be able to script some of this, but origins with more than one branch stemming from them might still cause trouble. If you keep backups, you could maybe restore a temporary repository and use it as source data for the script to determine which revisions should be tagged. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 105. I don't suffer from insanity. I enjoy every minute of it. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multi-user working directories
[EMAIL PROTECTED] wrote: Maybe I didn't explain things completely. With the Open Software model, the net result of a development is a set of source code. In a closed system, we must ship executables created from the source. (I'm not making any statement here as to either model being better so everyone put those flamethrowers away...). I don't see why this affects anything. Why would the need to compile before shipping affect source control? In our case, everyone does have their own "sandbox" to develop source. But at some point, the resulting software changes must be put together in to a release to be sent to customers. The area I'm talking about is this. We can't send 10 different sandboxes to the customer, we need to send a single set of executable. This one "official release" copy is responsible for creating that final copy (or in this case fixes to it) to be sent to a customer. Right. So, you need some way of keeping an official release copy up to date. What do you ship? We tag everything before we ship, so we can export a controlled copy. (Too many things change too fast to expect a consistent version otherwise.) You may do things differently, and may want to ship the head branch. I don't know, and it really doesn't matter. The Cederqvist et al. manual has a brief section on keeping a checked- out copy http://www.cvshome.com/docs/manual/cvs_18.html#SEC171 and while this refers to loginfo it seems to me you might do something with taginfo, to check out files into a standard location when they have tags that are moved. This looks like a job for a Perl script to me. It seems to me that It could be said that whomever makes a fix should build everything and ship it. We're talking about thousands of source files that can take upwards of 6 hours to compile, not to mention the 300Mb of resulting object code. It would be somewhat wasteful to recreate all this for every fix we ship. And yet this is what we do. We have several people whose job it is to ship what the client needs. They maintain their own exports and compile and ship. However, if you have an automatically checked-out version, then you can presumably have several people who can make and install the source code. It seems to me that that would solve your problem. Alternately, have a special username that is used only to maintain the master source files. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS Maintainer
Greetings. i am new to CVS but wish to become an observant "maintainer" for a certain set of files (in the linux area). that is, i just want to be notified when a file is modified (via email hopefully). i have searched the CVS site that i am using (http://vger.samba.org/cgi-bin/cvsweb/linux) for any information on how to go about linking myself into a list as a CVS "maintainer" but have been unsuccessful. any help is appreciated on this subject (details are great, as i don't really know much about CVS, but am investigating). thanks ahead of time, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multi-user working directories
Agreed. A shared account is plan B. Here's the scenario: A customer reports a problem. It is assigned to a developer. This developer has their own private sandbox in which to develop a fix. When they've come up with a fix, tested and reviewed it, and then checked it in. The developer then needs to build, what in the mainframe world is called a PTF, a set of executable (and other) files that include the fix. This PTF is suppose to be just the minimal changed code. Mainframe programmers are very paranoid, if it wasn't fixed, don't touch it. Used to be that some wouldn't even allow modules to be replaced, you had to patch the code in place. Yuk. This developer now goes to the common build sandbox, does an update to pick up this (and maybe other) fixes, and then a make. After the build completes, they pack up the changed executables (AKA binaries) and other files, and create a PTF package for distribution to customers. The problem here is that there are multiple developers and CVS will not even do a diff for a developer if it's been checked out by another. Thank you all for your time and patience. Looks like there might be an opening here for a future feature. Something like an override userid option or environment variable. Something that says, use this userid, not the one on CVS/Root. If I ever get the MVS port completed (it's working but barely), I might look into this. I can foresee other places where this would be handy. For instance, John calls up and says he broke foobar.c and asks you if you could look at it and see what's wrong. You cd over to his directory and look at his code and can't see anything either. You try and do a cvs diff to see what he's changed Thanks again. "Derek R. Price" [EMAIL PROTECTED] on 01/09/2001 10:19:28 AM To: Wayne Johnson/MINN/Candle@Candle cc: Alex Holst [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Multi-user working directories [EMAIL PROTECTED] wrote: The problem here is that we can't check it out every time we want to re-release the code. There are thousands of modules that would need to be re-compiled. We need to update the code that was already checked out and run make to build the updated modules. We then will distribute the changed executables. The problem is there could be any of several people who need to do this. If you don't want each person who may have to do it to check out a single "build space" once which they then reuse each time they need to rebuild, I'd probably go with a shared account or group access to your shared build space. I usually prefer to avoid the shared account, myself, for security reasons. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not barf unless I'm sick. I will not barf unless I'm sick. I will not barf unless I'm sick... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
question
i just did a post. but i also just noticed that the last date in this group is from 12-11-2000. rather old. is this group active? will my post get posted? thanks for any info, i am new to CVS too... tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multi-user working directories
Great. That works! That solved the problem. I didn't realize that -d overrode CVS/Root. Thanks. [EMAIL PROTECTED] (Larry Jones) on 01/09/2001 11:46:52 AM To: Wayne Johnson/MINN/Candle@Candle cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Multi-user working directories [EMAIL PROTECTED] writes: Thank you all for your time and patience. Looks like there might be an opening here for a future feature. Something like an override userid option or environment variable. Something that says, use this userid, not the one on CVS/Root. If all the files come from the same repository (and it sounds like they do), you can just use the -d global option on the command line to override CVS/Root. -Larry Jones That gives me a FABULOUS idea. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS For VMS
Rex, I would like a copy of the source, or patches for VMS. //Bill [EMAIL PROTECTED] wrote: Nobody's contributed a binary for OpenVMS since 1.9.27, so if you need anything more recent you'll probably have to do some porting work yourself. That may or may not be a big deal. I can compile 1.11 (client only) under OpenVMS 7.2 if anyone is interested. We also have local modifications to support vms wildcard filespecs if interested. Those interested send me mail or post to list and if there is interest perhaps i can send the binary to someone at openave for hosting. I can try to compile the server side, but I havent yet done so. Rex. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question
[EMAIL PROTECTED] wrote: i just did a post. but i also just noticed that the last date in this group is from 12-11-2000. rather old. is this group active? will my post get posted? thanks for any info, i am new to CVS too... You're probably using egroups to subscribe. I believe their system's been broken for some time. You can subscribe from the root server at: http://mail.gnu.org/mailman/listinfo/info-cvs . Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Justice: A decision in your favour. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
ignoring files when committing, but not when checking out
I want to have a file that gets checkout out when I do a 'cvs checkout', but is ignored when I do updates and commits. How can I set up cvs to do this. Thanks, Yon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Maintainer
[EMAIL PROTECTED] wrote: Greetings. i am new to CVS but wish to become an observant "maintainer" for a certain set of files (in the linux area). that is, i just want to be notified when a file is modified (via email hopefully). i have searched the CVS site that i am using (http://vger.samba.org/cgi-bin/cvsweb/linux) for any information on how to go about linking myself into a list as a CVS "maintainer" but have been unsuccessful. any help is appreciated on this subject (details are great, as i don't really know much about CVS, but am investigating). thanks ahead of time, http://cvshome.org/docs/manual/cvs_10.html#SEC87 Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- The advertisement is the most truthful part of the paper. - Thomas Jefferson ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvdiff - branch tracing log reporter [WAS: Re: Tools to generate report from logs?]
Righto.
cvdiff -h for help.
Basically,
cvdiff -rTAG
will generate a report of every checkin of every file
since that TAG was created.
It follows branches... So, if
foo.c
was TAG'd at 1.1, then eventually made
its way to 1.2.2.100, cvdiff will trace
1.1 - 1.2 - 1.2.2.1 ... 1.2.2.100
and ignore the revisions that are not a
part of the branch.
That is what the script was originally written for,
creating reports of logs along a branch.
Hope it helps.
Rob
#!/usr/bin/perl -w
# cvdiff
# attempt two to get what I want from cvs diff/cvs log
# Copyright(c) 1999-2001
# by Robert Bresner
# for Open Link Financial, Inc
# Insert GNU license here.
#This program is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation; either version 2 of the License, or
#(at your option) any later version.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
#
use strict;
use FileHandle;
use IO::File;
my( $Date1, $Date2, $DCtr); # -D args
my( $Rev1, $Rev2, $RCtr); # -r args
my $UseAreaprops = 0; # -R flag (sets rev2)
my $Recursive = 1; # -l flag
my $NewFlag = 0;# -N flag
my $Quiet = 0; # -q flag
my $verbose = 0;# -v flag
my @Files; # list of files to perform cvdiff on
my $NoTrace = 0;# Do not trace the log revision tree
my $ModRevs = 0;# Show revisions per mod, not per file
my %ModRevs;# Keep track of Module revisions for ModRev
my $ShortOutput = 0;# flag, module/file revision list only.
my( $Index, $LRev1, $LRev2, $Diff, $Module ); # These became global for -S mode...
my( $InputFile ); # Use input file instead of cvs command
STDOUT-autoflush(1);
GetArgs();
Go();
PrintModRevs();
sub PrintModRevs
{
return unless $ModRevs;
return if $ShortOutput;
foreach my $key( keys %ModRevs ) {
print "$key = $ModRevs{$key}\n";
}
}
sub Go
{
# Ok, first, for each file, get revision numbers and put in ascending order.
my $Cmd = "cvs -q diff";
$Cmd .= " -N" if $NewFlag;
$Cmd .= " -l" unless $Recursive;
$Cmd .= " -r $Rev1" if $Rev1;
$Cmd .= " -r $Rev2" if $Rev2;
$Cmd .= " -D $Date1" if $Date1;
$Cmd .= " -D $Date2" if $Date2;
$Cmd .= " @Files" if @Files;
# If a file hasn't changed from tag1 to tag2, then cvs output will be empty,
# and this file will be skipped.
# Diffs are done first to get the two revisions that I will trace.
#cvs-1.10.8.exe diff -rMY_TAG buildsql
#Index: buildsql
#===
#RCS file: /big2/cvs/master/olf/bin/buildsql,v
#retrieving revision 1.32
#retrieving revision 1.291
# The two retrieving revision lines are all I need (unfortunate that I have to
# get them through a cvs diff call, but what are ya gonna do?)
# Once I have the revision numbers (the from and to of the log trace) I can call
# cvs log.
my $FH;
if( $InputFile ) {
# An input file can be created by doing a full cvs log on a file dir or mod,
$FH = new IO::File( "$InputFile", 'r' )
or die "Could not open input file $InputFile: $!\n";
}
else {
$FH= new FileHandle;
open( $FH, "$Cmd|" )
or die "Could not open pipe '$Cmd|': $!\n";
}
binmode $FH;
while( $FH ) {
/^Index: (.*)$/ and $Index = $1;
/^retrieving revision (.*)$/ and not $LRev1 and $LRev1 = $1;
/^retrieving revision (.*)$/ and $LRev1 and $LRev2 = $1;
/^RCS file:\s+(.*)\,v/ and do {
my $D1 = $1;
if( $D1 =~ /.*?\/olf\// ) {
( $Module = $D1 ) =~ s/.*?\/olf\///;
$Module =~ s/^(.*)\/.*/$1/; # remove filename from module name
} else {
$Module = '';
}
print STDOUT "MODULE: $Module\n" if $verbose;
};
/^diff -r\d/ and do {
$LRev2 = "NONE" unless $LRev2;
DiffThisFile($Index, $LRev1, $LRev2 );
$Index = $LRev1 = $LRev2 = undef;
};
}
}
sub DiffThisFile
{
# Not _REALLY_ a diff, per se.
# I got the 2 revision numbers ( the from and the to, if you will )
# from the diff above.
# First I want to make sure the From #.# precedes the To #.# (damn users)
# then I want to trace the From #.# to the To #.#, reporting the logs
# of each step.
my( $Index, $LRev1, $LRev2 ) = @_;
# print "INDEX: $Index LREV1:
Re: CVS with cvsroot on a samba mount
Sorry. No new solution. Like I said the first time through, the easy answer is in switching to pserver mode and the second best probably lies in figuring out which flags need to be changed on the SAMBA server to allow CVS to operate properly across the share. You might be better off with pserver anyhow. Other problems may decide to rear their heads later, due to, say, EOL conversions or whatever, and may turn out to be more subtle and harder to fix. Of course if you want to do the testing debugging, we'll read all the advice you can send. :) Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- A mathematician is a blind person in a dark room looking for a black cat which isn't there. - Charles R. Darwin Frank-Michael Moser wrote: Hi, sorry for cantacting you directly. I found an message posted by you in an archive: I tried tagging my src directory. It complained, saying something like: Cannot do 'WinUtil.h, -- WinUtil.h,v . WinUtil.h,v already exists. I've seen something like this using samba to access a repository on a remote machine. The problem seemed to be a symptom of the operations samba would and wouldn't allow across the share. I ended up switching to pserver after a couple of hours of trying to figure out samba config files and realizing that if I DID find the answer I was going to have a hell of a time persuading the sysadmin team that the settings should be changed. Do you know, may be, any solution by now, so please let me know. Otherwise trash my mail. Thanks, Frank-Michael. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ignoring files when committing, but not when checking out
See: http://cvshome.org/docs/manual/cvs_18.html#SEC173 - Dennis - Original Message - From: "Yon Rosenthal" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 09, 2001 11:20 AM Subject: ignoring files when committing, but not when checking out I want to have a file that gets checkout out when I do a 'cvs checkout', but is ignored when I do updates and commits. How can I set up cvs to do this. Thanks, Yon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ignoring files when committing, but not when checking out
Yon Rosenthal wrote: I want to have a file that gets checkout out when I do a 'cvs checkout', but is ignored when I do updates and commits. How can I set up cvs to do this. Why bother? Is it so hard to set up a convention among your developers that no one touches the 'README' file or whatever? I suppose if permissions were really important, you could set up a dir which your developers only have read access to that gets checked out with your project. That will prevent commits and if no changes get committed, no updates can be pulled down... Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- OPHELIA O, what a noble mind is here o'erthrown! The courtier's, soldier's, scholar's, eye, tongue, sword, Th'expectancy and rose of the fair state, The glass of fashion and the mould of form, Th'observed of all observers, quite, quite down! And I, of ladies most deject and wretched, That sucked the honey of his music vows, Now see that noble and most sovereign reason Like sweet bells jangled, out of time and harsh, That unmatched form and feature of blown youth Blasted with ecstasy. O, woe is me T'have seen what I have seen, see what I see! - Hamlet, Act III, Scene 1, Lines 151-162 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Remove (empty) directories
Jakob Hummes wrote: After deleting old files (well actually moving them into an old directory) under CVS, I have the minor problem that the directories cannot be removed (at least not with my WinCVS client). Do I have to remove them manualy on the CVS server or is there a client side command to do that? Pass '-P' into 'cvs up' and 'cvs co'. The usual thing is to use you .cvsrc to do it. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "It's difficult to work in a group when you're omnipotent." -Q, "Deja Q" ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ignoring files when committing, but not when checking out
Yon Rosenthal writes: I want to have a file that gets checkout out when I do a 'cvs checkout', but is ignored when I do updates and commits. How can I set up cvs to do this. You can't. -Larry Jones The problem with the future is that it keeps turning into the present. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: updating dependencies
Colby Allred wrote: I am *very* new to CVS and have a user that wishes to emulate a behaviour similar to commitinfo. What he wants is this: He has a perl script under cvs control, and it depends on other files under cvs control in other projects. Is there a way to have those other files updated when he performs an update on his perl script? Check all modules out as subdirs of '.', including the Perl script. Then 'cvs update .'. Alternatively, use loginfo to keep a group shared area updated for the dependencies ( http://cvshome.org/docs/manual/cvs_18.html#SEC173 ). As long as you have your PERLLIB variable or whatever it was set right, things should work. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- In matters of style, swim with the current; In matters of principal, stand like a rock. - Thomas Jefferson ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ignoring files when committing, but not when checking out
Oops. I guess I didn't read your question carefully enough before responding with my first reply. Sorry Yon. - Dennis - Original Message - From: "Yon Rosenthal" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 09, 2001 11:20 AM Subject: ignoring files when committing, but not when checking out I want to have a file that gets checkout out when I do a 'cvs checkout', but is ignored when I do updates and commits. How can I set up cvs to do this. Thanks, Yon ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS with cvsroot on a samba mount
"Derek R. Price" wrote: Sorry. No new solution. Like I said the first time through, the easy answer is in switching to pserver mode and the second best probably lies in figuring out which flags need to be changed on the SAMBA server to allow CVS to operate properly across the share. You might be better off with pserver anyhow. Other problems may decide to rear their heads later, due to, say, EOL conversions or whatever, and may turn out to be more subtle and harder to fix. you might want to look back in the archives (if the archives are working) for a thread running from 13 Dec 2000 through 14 Dec 2000 with the subject of "SV: Different kind of access methods" for some of those more subtle problems. Of course if you want to do the testing debugging, we'll read all the advice you can send. :) Derek snip stddisclamer.h
Re: question about :local: access to repository on Windows box (USERNAME -- ?)
I'm not exactly sure what you mean here. If the repos is :local:, then it's not possible to log in. Period. If you want to track who is using it, as you had in the subject, %USERNAME% works as long as the user actually logged in (problem for Win9x, because they don't require login). After that, you put correct permissions on the repository so that only allowed people have access. I guess that's the closest thing to a login when using :local:. If this isn't what you meant, then please explain again. Mike "X.X." wrote: Hello everybody. I'm sorry, but i have not found yet an answer to one important question: how one can log in with personal user_name to the `:local:' repository. It's so important, because we will keep the repository under Windows (not on UNIX box). If you have any idea or a "how to" link, write me, please. Thank you Best regards, Alexei Lyubimov PS: It seems, that in Cederqvist it is nothing about too :( ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about :local: access to repository on Windows box (USERNAME -- ?)
True, but if there are file permissions (there won't be for Win3.11, but will be for WinNT, if it's Win9x, then I think it's possible to circumvent any local file permissions), then the access to the CVS repository is based on the file permissions. //Bill Michael Peck wrote: I'm not exactly sure what you mean here. If the repos is :local:, then it's not possible to log in. Period. If you want to track who is using it, as you had in the subject, %USERNAME% works as long as the user actually logged in (problem for Win9x, because they don't require login). After that, you put correct permissions on the repository so that only allowed people have access. I guess that's the closest thing to a login when using :local:. If this isn't what you meant, then please explain again. Mike "X.X." wrote: Hello everybody. I'm sorry, but i have not found yet an answer to one important question: how one can log in with personal user_name to the `:local:' repository. It's so important, because we will keep the repository under Windows (not on UNIX box). If you have any idea or a "how to" link, write me, please. Thank you Best regards, Alexei Lyubimov PS: It seems, that in Cederqvist it is nothing about too :( ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about :local: access to repository on Windows box (USERNAME -- ?)
Bill Whiting wrote: True, but if there are file permissions (there won't be for Win3.11, but will be for WinNT, if it's Win9x, then I think it's possible to circumvent any local file permissions), then the access to the CVS repository is based on the file permissions. That's what groups are for? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- A burp is not an answer. A burp is not an answer. A burp is not an answer... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs [server aborted]: out of memory; can not reallocate xxx bytes
One of my users complained she got this message whenever she checked out or updated in her module. I found that she had committed two of her binaries; one was 11Mb, the other was 7Mb. When I removed those files, the checkout/update worked. I am running cvs 1.11 pserver with "-T /tmpcvs", where /tmpcvs is a 3Gb filesystem. There is 2Gb of RAM on the server, which is HP 10.20. /tmp is 1.1Mb (but I hope it isn't being used). The "xxx bytes" that can not be reallocated seems to be fixed depending on what file I am trying to checkout. For the file of size 11,456,355, xxx is 21968. For the file of size 7094501, xxx is 14262. Funny thing is, there are larger files that I *CAN* check out without a problem. What appears to be a distinguishing feature is that they only have a single revision in the tree (1.1). In fact, I can checkout 1.1 of the 2 files that gave me trouble above. So I'm guessing that CVS is running out of something while trying to reconstruct revision 1.4 (in the above example). Is it really memory, or could it be temp disk space (which I was hoping would be /tmpcvs, as specified on the inetd.conf command line, and not /tmp)? This might sound like a stupid question, but I thought I remember a problem with the size of the history file that also caused this message to appear. Wait. I seem to remember something about the maximum amount of memory an application is allowed to request. Thanks for any help! :)hal mahaffey
Re: cvs [server aborted]: out of memory; can not reallocate xxxbytes
We had this problem on a BSD box here. Turns out there were some restrictions in place on how much swap space a user program could use, and cvs was exceeding it. Our IS guy made some changes on the machine and it solved the problem. Dave on 1/9/01 2:54 PM, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: One of my users complained she got this message whenever she checked out or updated in her module. I found that she had committed two of her binaries; one was 11Mb, the other was 7Mb. When I removed those files, the checkout/update worked. I am running cvs 1.11 pserver with "-T /tmpcvs", where /tmpcvs is a 3Gb filesystem. There is 2Gb of RAM on the server, which is HP 10.20. /tmp is 1.1Mb (but I hope it isn't being used). The "xxx bytes" that can not be reallocated seems to be fixed depending on what file I am trying to checkout. For the file of size 11,456,355, xxx is 21968. For the file of size 7094501, xxx is 14262. Funny thing is, there are larger files that I *CAN* check out without a problem. What appears to be a distinguishing feature is that they only have a single revision in the tree (1.1). In fact, I can checkout 1.1 of the 2 files that gave me trouble above. So I'm guessing that CVS is running out of something while trying to reconstruct revision 1.4 (in the above example). Is it really memory, or could it be temp disk space (which I was hoping would be /tmpcvs, as specified on the inetd.conf command line, and not /tmp)? This might sound like a stupid question, but I thought I remember a problem with the size of the history file that also caused this message to appear. Wait. I seem to remember something about the maximum amount of memory an application is allowed to request. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [login aborted]: recv() from server cvs: EOF
Found this on mail-archive.com: http://www.mail-archive.com/info-cvs@gnu.org/msg02526.html . If the first mail doesn't help, try following the thread links at the bottom of the page. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- There is not a truth on earth which I fear or would disguise. But secret slanders cannot be disarmed, because they are secret. - Thomas Jefferson to William Duane, 1806 Sandra Wittenbrock wrote: Hi, Suddenly, I am having trouble connecting to cvs from my computer. From other computers, I can connect. My computer is running Solaris. I have CVSROOT and CVSHOME set. The error is: plato: cvs login (Logging in to loginname@cvsserver) CVS password: cvs [login aborted]: recv() from server cvs: EOF I checked the archives, and saw a couple questions about the same problem, but no answers. Any ideas? Thanks, Sandra ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS For VMS
Bill Whiting wrote: Rex, I would like a copy of the source, or patches for VMS. //Bill [EMAIL PROTECTED] wrote: Nobody's contributed a binary for OpenVMS since 1.9.27, so if you need anything more recent you'll probably have to do some porting work yourself. That may or may not be a big deal. I can compile 1.11 (client only) under OpenVMS 7.2 if anyone is interested. We also have local modifications to support vms wildcard filespecs if interested. Those interested send me mail or post to list and if there is interest perhaps i can send the binary to someone at openave for hosting. I can try to compile the server side, but I havent yet done so. Same here. I'll check in anything needed to get CVS to compile under VMS as well as seeing that a binary gets posted at OA. Of course, a binary that does client/server probably appeals to a wider market, but I'll take whatever you can send me. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not fake my way through life. I will not fake my way through life. I will not fake my way through life... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
A Question
Hi all! I am new to CVS and the UNIX environment. We are currently operating from 2 locations - India and US. The latest checked out build in the US office is ftpied to us in India. We at our end are required to put it in CVS and keep on updating it with the new builds received. We have put the first build into CVS. How can we update this build with the next one received? Do we have to first checkout the first build somewhere at our end and then update it? Please let me know the whole procedure for this. Thanks in advance. Manish _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
