RE: CVS Server times
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of David A. Bartmess Sent: vendredi 25 février 2005 06:53 On Thursday 24 February 2005 08:24 am, Jim.Hyslop wrote: rakesh mailgroups wrote: does anyone know if the repository server having a different time than local PCs will cause issues with CVS? None whatsoever. CVS was designed to be able to operate with workstations in multiple time zones (unlike, say, Visual Source Safe). All times are converted to UTC before being stored in the repository. But if a local PC was used to work on files, having a current time at checkin of 11:30 MDT, and the server at time of checkin is 13:35 EDT, this could seriously screw with any automation that relies on the datetime stamp to know if a build has already included that change (i.e., cruisecontrol). Uhm? EDT != UTC MDT != UTC *All* CVS Client - Server and Server - Client communication is (virtually) done in UTC. Meaning, as Jim said, local PC uses MDT, talks to CVS server, and CVS server converts to UTC, and also CVS server uses UTC, talks to CVS client, and CVS client converts to MDT. The EDT settings of your server are totally unimportant within the CVS server! proud We (as in previous job) used to manage a CVS repo in Germany, and access it from within the States. No problems in timing *ever* occurred. /proud Cheers, Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.4.0 - Release Date: 22/02/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.4.0 - Release Date: 22/02/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: FAQ-O-Matic pserver protocol
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Baushke Sent: dimanche 13 février 2005 09:39 To: Guus Leeuw jr. Cc: info-cvs@gnu.org Subject: Re: FAQ-O-Matic pserver protocol -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guus Leeuw jr. [EMAIL PROTECTED] writes: Hence I am looking at the pserver protocol, so I figured, it is a FAQ. Now depending how you interpret FAQ (asked or answered), I was right ;) It's apparently asked often, but https://ccvs.cvshome.org/fom//cache/446.html gives no answer :( Search the info-cvs archives and you might have more luck. The short answer is don't use it. Move along, this is not the protocol you are looking for... The hence above was indicating that I am writing a passwd command for the pserver stuff, as Jim suggested would be a nice feature... On dev, so far, no hard statement against doing this... If you think, I shouldn't be doing this, please state so, and I'll back out doing more important stuff... Can anybody tell me where the doc is? Can't seem to find it in the cvs1-12-11 branch... For HTML Cederqvist manual for cvs 1.12.11, look here: https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs.html For the client/server protocol, look here: https://ccvs.cvshome.org/source/browse/ccvs/doc/cvsclient.texi You should be able to find a doc/cvsclient.info file and a doc/cvsclient.ps -- these forms of the document describe both the pserver framework and protocol (as well as the kserver and server protocols). If you plan to read the document closely and you actually care about security, issue ear-plugs to your neighbors so that your screams will not distrub them too much. OK, thanks ;) In general, my personal opinion is that the pserver and kserver protocols should be removed from the cvs sources completely. It is never secure to run the cvs executable as root which is required to use the pserver protocol. The cvs sources were never designed with security in mind and running them as root is idiocy. (Just say no.) You're kidding right? Root is a good user(TM), no? If you are using pserver, I hope it is on an isolated LAN with lots of firewalls and does not control any sources you really need to be kept secure. I also hope that you are making plans to transition away from pserver usage as fast as possible. I use it since a couple of years on a LAN that has merely an ADSL router listening, and a linux based firewall blocking... in between the LAN and the server is still an SMC Barricade allowing nothing from the outside to create a network session... Guess this is triple secure... I get a lot of probes, but they don't make it through the server... So that should be cool... Summary: Friends don't let friends deploy cvs pserver configurations... Sure enough... What about the people that do use pserver, and want their users to change their passwords from CVSROOT/passwd? No change today... Not securely, that is. So we might consider implementing it, no? Simply sending a scrambled password over the *LAN* can't hurt too much... For WAN, pserver is quite different ;) Anyways... Development stopped until verdict is received ;) Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: FAQ-O-Matic pserver protocol
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Baushke Sent: dimanche 13 février 2005 10:54 To: Guus Leeuw jr. Cc: info-cvs@gnu.org Subject: Re: FAQ-O-Matic pserver protocol -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guus Leeuw jr. [EMAIL PROTECTED] writes: Have you considered moving to the CVSNT fork of CVS? (Yes, it runs on boxes other than Windows.) No, and I won't. I am a long time believer of CVS pure ;) In general, my personal opinion is that the pserver and kserver protocols should be removed from the cvs sources completely. It is never secure to run the cvs executable as root which is required to use the pserver protocol. The cvs sources were never designed with security in mind and running them as root is idiocy. (Just say no.) You're kidding right? Root is a good user(TM), no? Actually, no, I am not kidding. Well, I was ;) If you look at the main page (https://www.cvshome.org/) you will see that even cvshome.org was subject to an attack on a cvs security violation. Yeah, I've seen that coming along. If cvs runs as root and allows connections on port 2401, then it had better be very well audited and have a very tighly written security model for dealing with all of its inputs and avoid all possibility of a privilege escallation that results in abuses to that connection. There is too much #ifdef'd code and hard to semantically verify code in the current pserver code path for any sane security expert to give anything better than an 'unsecure' rating to it. One way to deal with this problem would be to do something like OpenSSH does with priviledge separation, so that only a tiny fraction of well tested and closely examined code will ever run as root and that it carefully performs its authentication checks and validations. Further, it would not provide for a password that is only obscured on the wire, but is otherwise transmitted in the clear for use in any kind of replay attack you wish to imagine. Hmm... Good idea... Takes a long time to implement, though... See below. Sure enough... What about the people that do use pserver, and want their users to change their passwords from CVSROOT/passwd? If they are going to move to cvs 1.12.x, then the could go ever further down the road to perditions flame and use PAM authentication and change their password via a NIS protocol if they want. I'd assume most people out there use the CVS 1.11 branch of things, so I'd stick passwd in the feature release for the hard-edge to test, and then maybe a back-port? No change today... Not securely, that is. Hmmm... that really is very funny. Sending the password in a completely reversible encoding otherwise in the clear to do normal operations is secure? True, but such is the nature of pserver by default. So we might consider implementing it, no? I can't stop you. Well, if I'd do it, I'd do it because of: 1) It seems useful (Jim suggested such) 2) Larry, Derek, and you Mark would want it in the general CVS... Simply sending a scrambled password over the *LAN* can't hurt too much... For WAN, pserver is quite different ;) Well, the distance from a LAN to a WAN is a lot smaller than you might believe. Sure, but LAN is controllable... WAN is not so much controllable... Anyways... Development stopped until verdict is received ;) CVS is open source. There is nothing to say that you might not provide whatever patches you want to them and make them available to whoever wants them. Yeah, again, I'm not going to devote my time to CVS development, when I'm already certain the code's not gonna make it... That seems fair to me ;) That said, if you really are planning to cleanup pserver to make it 'secure' for changing a password, maybe you can find the time to do a more secure replacement code base for the pserver implementation instead? If you can get security folks to go thru all possible code paths and shake out the next big bug (and fix it), then I am sure a lot of folks would appreciate your work. Maybe... We'll see. Let me first tackle the password stuff, and later, I might have time to go about pserver in general... A strong believer in 'cvs password' should go and look at what CVSNT does. They already implement a 'cvs password' command. The protocol element they added is passwd so if you use that token in any code you submit to the CVS version from cvshome.org, then you MUST follow their protocol exchange rather than implement your own for CVS). We have tried very hard to ensure that nothing they add or we add will break the basic compatibility of a mixed client/server with CVSNT and CVS acting as either role. You will want a copy of the cvsnt sources. It may be fetched here: cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/cvs co cvsnt you would need to look at the cvsnt/src/passwd.c sources for their implementation. The cvsnt/doc
FAQ-O-Matic pserver protocol
Hiddi'up, Hence I am looking at the pserver protocol, so I figured, it is a FAQ. Now depending how you interpret FAQ (asked or answered), I was right ;) It's apparently asked often, but https://ccvs.cvshome.org/fom//cache/446.html gives no answer :( Can anybody tell me where the doc is? Can't seem to find it in the cvs1-12-11 branch... Cheers, Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: from cvs@localhost.localdomain
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of Parvinder Singh Arora Sent: vendredi 11 février 2005 17:58 To: info-cvs@gnu.org Subject: from [EMAIL PROTECTED] Where do i need to update this at my server ? Read the sendmail/postfix manual, and the Admin Guide of your OS, so as to know how you set hostname / domainname for a server. Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Changing passwords for CVS Users (pserver protocol)
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of Paola Attadio Sent: vendredi 11 février 2005 15:15 To: info-cvs@gnu.org Subject: Changing passwords for CVS Users (pserver protocol) Hello, I have configured CVS linux version. I use pserver protocol, and I have configured cvs users ($CVSROOT/CVSROOT/passwd). This users are independent of the linux users. I have a script perl to generate passwords. The user use WinCVS. The user don't have access to the linux. In this context, I'd like to allow to the cvs users to change your password without to access the linux machine. Somebody knows some tool and/or way to do this? The only feasible way to do this is to provide a program or such that will be able to do the change on the machine. CVS pserver protocol does not allow for password change. Maybe Mark wants to add it in a feature release, and if so, Id be happy to provide the code for it. Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branches
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of Annette Roll Sent: mardi 8 février 2005 16:46 Is there any query I can run to find all branches in a repository? $ find . -name * | xargs cvs status -v This will produce *a lot* of information, though. Cheers, Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 07/02/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 07/02/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: howto: real author vs. repos author
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of Uwe Mayer Sent: dimanche 6 février 2005 03:20 Subject: howto: real author vs. repos author I maintain a project under GPL. People started using it, sending me patches and extensions to the program. I maintain a local versioning system to keep track of revisions. I need to know the propper way how to credit the users for patches or extensions send to me and having a $Author$ keyword substitution from my versioning system in the header of my files. According to Cederqvist, Chapter 12 (stable release 1.11.19): $Author$ The login name of the user who checked in the revision. According to GNU standards, which you are bound to when using GPL, there *must* be a file called AUTHORS that *should* contain full name, current email address and *could* contain the offered contributions. Sounds all fairly simple to me: a) Put the details in AUTHORS b) Give them write access b) is not as good as a) though: revision 1.1 checked in by 'kljhasd', revision 1.2 checked in by 'asfda'... And $Author$ now points to 'asfda', and 'kljhasd' can only be found browsing the revision history of that file, or through cvs annotate. Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.5 - Release Date: 03/02/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.5 - Release Date: 03/02/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Can I adding earlier history to a repository
Darren, There are 3 possible scenarios' I can think of: 1) Import the earlier release 2) Create a new area 3) Hand hack 1) Import the earlier release 1-1) Tag the current revision on the main trunk for all files 1-2) Import version 1.0 to the vendor branch 1-3) Merge that version to the main trunk, having the vendor branch overwrite the trunk in case of conflicts. 1-4) Check out that copy 1-5) Merge in the changes from the tagged revision from step 1-1 2) Create a new area 2-1) Import version 1.0 into a new module 2-2) Check out the main trunk 2-3) With help of diff and patch, update the sandbox from 2-2 with all needed patches from the previous module 2-4) Check in 3) Hand hack 3-1) Don't do it ;) If I were you, I'd take route 2) Guus -Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of Phillips, Darren (UK) Sent: jeudi 27 janvier 2005 11:59 To: info-cvs@gnu.org Subject: Can I adding earlier history to a repository Hello, I have created a cvs area which the team have been using for a few weeks now and various checkins and new files have been added. Unfortunately the code I started the cvs area with was a later release than I should have configured. It is there any way of adding the earlier release without losing all the updates since I started the area. Ie. effectively adding a new version 1.1 and shuffling all the exsting files up a version. If there isn't - which I suspect will be the answer - if I create a new area based on the earlier release, then checkin in the later release, is there an easy way to replicate the changes that the team have made to the later release. regards Darren. This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 21/01/2005 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 21/01/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 21/01/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 21/01/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: how to get history
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: lundi 24 janvier 2005 01:48 I wonder what command should I use to get list of tags as history... cvs status -v Seems to be tricky - I could not figure that out myself. Not trickier than reading the manual... ;) Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 21/01/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 21/01/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS for Small office
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of Linux New bie Sent: dimanche 23 janvier 2005 22:01 Is it a way I can have different write/read files for each of the directories under CVSROOT. So that I can create the different write/read files which hold different users in the directory level. Please let me know the best practice to implement the above scenarios a) Read up on Unix/Linux filesystem security b) Read the CVS manual c) Logically combine the gathered information In short: Use group permissions on your filesystem, and put the appropriate people in appropriate Unix groups. Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 21/01/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 21/01/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Scmbug configuration
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: jeudi 20 janvier 2005 19:41 does anybody has any experience with Scmbug? I installed it but I don't know how to configure or use it! The documentation doesn't give any detailed descriptions. Since your question is about scmbug, why don't you ask the question on the scmbug mailing list? Also there seems to be quite a manual out there... Cvs != scmbug... Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs pserver problem and xinetd. connection refused
-Original Message-
From: [EMAIL PROTECTED] [mailto:info-cvs-
[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: mardi 18 janvier 2005 23:19
[snip]
3. added following line to the /etc/xinetd.conf file so xinetd listens to
port
2401 and knows to run command cvs pserver when it receives a connection:
{
port= 2401
socket_type = stream
protocol= tcp
user= root
wait= no
type= UNLISTED
server = /usr/bin/cvs
server_args = -f --allow-root=/cvs pserver
disable = no
}
[snip]
Lastly, I've looked at the /var/log/messages file and do not see
anything of use to me in this matter. There is absolutely nothing in
this file about cvspserver or pserver. The only thing I see is the
following when xinetd is restarted:
Jan 19 15:05:01 emobilebugzilla xinetd[8501]: missing service keyword
[line=21]
If anyone has any sort of clue as to why this is happening please let
me know. Most importantly, if someone knows how to fix it I will be
extremely grateful. Thank you for your time.
Moah yes... According to 3. above there is no service given for the block...
So, that's the reason why xinetd complains.
Some other comments:
1) You generally dont need to include the service config in xinetd.conf,
but rather in its own file in /etc/xinetd.d/ (as you seem to do *also*)
2) You should not need the port assignment in your config... Given the
proper service directive and name, xinetd should be able to figure the port
number through nsswitch and friends.
Guus
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/01/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/01/2005
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
RE: two text formats in one module
Peng Jian, You might want to use tools like unix2dos and dos2unix on the unix machine to convert files. Guus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: mardi 4 janvier 2005 04:32 To: info-cvs@gnu.org Subject: two text formats in one module Hi, In a module, some text files are of Windows format and others are of Unix format. I know that there is an option Checkout text files with the Unix LF (0xa) in WinCvs, but it doesn't seem to help much in this case. Now I have to treat them all as Windows format and change some of them to Unix format by hand. Are there better ways to do this? Regards, Peng Jian ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Size problem
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of Hridyesh Pant Sent: jeudi 25 novembre 2004 13:34 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Size problem no reply form anybody pls help... There is no other solution than to do it by hand (if you are really stuck with putting that binary file in the repository). Please also note that replying to all is best done only via the list. ;) Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.788 / Virus Database: 533 - Release Date: 01/11/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Issue with identifying scripts within a repository
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of Jeeva Sarma Sent: mardi 23 novembre 2004 20:18 To: [EMAIL PROTECTED] Subject: Issue with identifying scripts within a repository We have a repository to store scripts which are run against databases. When the developers check-in the scripts, no one knows if that will go all the way to prod. It has to pass qc, or may have some other issues, so everything that is checked in may not go to prod. All approved scripts will run once in 2 months.So we need a way to identify all these scripts from the others in the repository.Pls note that the number of these scripts is very high. Why don't you handle the scripts with development life cycle? Dev-Test-Prod. Dev == CVS HEAD Test will be a tagged version of the scripts package: V1_0_TEST. This package goes to Test. Dev will be developed with new features if needed. If need be, V1_0_TEST will be branched, so that local fixes can be applied. Once Test is happy, tag that with V1_x_PROD, and move it to prod. At this point in time, merge the changes on the V1_0_TEST branch back to main stream development (== HEAD), resolve the conflicts, and develop further. Just my 2 cents, Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.788 / Virus Database: 533 - Release Date: 01/11/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Merging contents of two repositories into a single one.
-Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of Ivan Teliatnikov Sent: jeudi 11 novembre 2004 01:42 Historically I have two CVS repositories located on the same CVS server. /opt/cvs/cvs1 /opt/cvs/cvs2 Each location has a number of independent projects. Is is possible to merge the two CVS locations into one without loosing history information? Are they truly independent? Easy. Make sure everybody has his stuff checked in. Make a backup. Copy cvs1 to cvs2. Change (x)inetd if you run pserver. Send advertisement about the new $CVSROOT to whom is concerned. Have them check out a new sandbox. If they are not truly independent (ie both repo's have a module with the same name) you might want to check which repo is the better... and then do the copy stuff. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.788 / Virus Database: 533 - Release Date: 01/11/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: merged code from branch to MAIN
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Oosterholt Sent: dinsdag 9 november 2004 11:26 branch visualisation: /- branch B --- / --/ MAIN trunk Our MAIN branch was very old, only development on branch B was performed. We wanted code from branch B to overwrite code in MAIN. This was causing very many merge conflicts. So we copied files from a branch B checkout to a MAIN checkout and commited the code. Aua Now, each time when we try to merge code from branch B to the MAIN trunk, *ALL* files are flagged to be modified and many files give merge conflicts. As Cederqvist put it: can have undesirable side effects... How do we solve this problem? How can be do a branch merge again and only modified files get merged? Either: * You happen to have a backup of the Repo before you did the hack? Re-install it, but only if you also have a copy of the checked out and possibly changed branch... ;) OR * No backup? OK... For every file in the checked out unmodified HEAD, grab the current revision, go two revisions back, (if 1.5 is current, than 1.4 is the copy, and 1.3 is the last known good...): cvs upd -j 1.5 -j 1.3 file cvs ci At this stage, you have a clean repository again... Now just go to the branch checked out version, cvs -nq upd and if needed cvs ci. Branch is OK now as well. Go to the checked out and up to date sandbox of HEAD. cvs upd -j branchname, resolve the conflicts, and cvs ci... Then go to the branch sandbox and cvs tag -f branch_merge_tag (use a decent name!) Next time around, when you merge changes from the branch into the TRUNK, use the branch_merge_tag you created above. The conflict section is kinda hard, but then again, if you resolve them proper, you're fine. For ever ;) And there might be some tools that could help you resolve the conflicts... Or write a quick perl that greps for , and in every source file... Display the differences, ask which one to keep, and write all that proper code back to the file. Success, Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.784 / Virus Database: 530 - Release Date: 27/10/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Join is replacing?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeeva Sarma Subject: Join is replacing? I have one question. When we do a join between 2 revisions, say from the branch to trunk, is it the same as replacing the file on trunk with the one on branch? A join basically merges two revisions from different branches. If you made changes on both branches after you branched off, you are likely to get some conflicts. If OTOH you made changes only to the branch revision after branching, you are most likely to replace the one on the trunk ;) If, though, you only changed the trunk revision after branching, nothing should be done. Cheers, glj --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.784 / Virus Database: 530 - Release Date: 27/10/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs bulk remove/add
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frederic Brehm Subject: Re: cvs bulk remove/add At 03:47 PM 11/8/2004, Alex Valentine wrote: One of our developers has a simple task. He wants to move a boatload of files from one directory /lib to a new directory /src/lib. How can this be done in CVS without having to individually add and remove each file? CVS by itself does not help you automate this task. Write a script. hack Or move the directory in the repository /hack glj --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.784 / Virus Database: 530 - Release Date: 27/10/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: AW: No conflits but no importing at all!
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: vrijdag 8 oktober 2004 1:19 Betreff: Re: AW: No conflits but no importing at all! the command was: cvs import -m First import to my laptop chap2 eduardo start The output of cvs was: a) two blank lines b) No conflicts c) two blank lines ls -l total 0 This output was inside /home/eduardo/my_latex_files If this is the case, then there was nothing to import. Which means no conflicts. Which is good ;) But still, removing that directory and cvs co my_latex_files should bring it back. Also make sure that you always copy [EMAIL PROTECTED] I might not answer to CVS questions not send to the list. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: Best practise with tagging
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Xanana Gusmao Gesendet: donderdag 7 oktober 2004 8:50 Betreff: Best practise with tagging Before any public release of the software, you must tag the module. I would suggest Before any ... You must branch the module with a release tag Since a tag does not always result in a branch... A branch would be better in this case if you need to fix a bug in the release and you cannot do it on the main trunk because some heavy development has been done introducing new features that the original release was not supposed to have. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: AW: Best practise with tagging
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Xanana Gusmao Gesendet: donderdag 7 oktober 2004 10:52 Betreff: Re: AW: Best practise with tagging Guus, I would suggest Before any ... You must branch the module with a release tag Yes that makes sense. Code release should come from a branch which is the stable version of everything from HEAD. That branch should be tagged. The next question: In a tagged branch, is it advisable to retag it ? What scenarios would force us to retag it? I think it should be left alone indefinitely. All bug fixes on the branch will sooner or later be merge back to the trunk. Every time you do a merge from the branch back on the trunk, you need to cvs tag -f branch_merged the branch , so you can upd -j branch_merged -j branch the next bug fix to the trunk. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: Best practise with tagging
Von: Jim.Hyslop [mailto:[EMAIL PROTECTED] Guus Leeuw jr. wrote: -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] Before any public release of the software, you must tag the module. I would suggest Before any ... You must branch the module with a release tag I disagree. Branches can be very complex to manage. I recommend creating them only when necessary. If you have a non-branch symbolic tag applied, it is trivial to create a branch *when needed*. True, but what about a person doing cvs tag release_1_0_0 and later (half a year) cvs tag release_1_0_0? CVS will tell the person that the tag already exists... If (s)he thinks to be smart, (s)he might want to try cvs tag -f release_1_0_0 at which point you loose your release revision and there'll be no way to bug fix the client without feature upgrade. Of course you can say people shouldn't be too silly, but things go wrong when people work ;) Is a branch really expensive and difficult to manage if you don't touch it often? Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: cvs lock ..
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Gurpreet Singh (SCM) Gesendet: donderdag 7 oktober 2004 11:06 Betreff: cvs lock .. It gives a message waiting for sys_user's lock at CVS_File_Path I've seen this only happening when somebody did a cvs ci and forgot about it, or when a CVS process dies somehow before nicely cleaning up. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: Please help troubleshooting connection problem via SSH
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Chris Weiss FYI - the output of -t update is (the user/servernames have been changed to protect the innocent): C:\c:\Program Files\gnu\WinCvs 1.3\cvs -z9 -t update - main loop with CVSROOT=username@cvs.servername.com:/usr/local/cvsroot And that's it... it'll sit until we ctrl-C out of it... Remove the -z9 and retry. (Not that I think it makes any jack difference) Plus isn't CVSROOT meant to say something like :ext: in case of SSH? (I don't use SSH tunnels with my CVS so I really don't know, but from the top of my head...) Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: No conflits but no importing at all!
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von [EMAIL PROTECTED] cvs ci -m First import to my laptop chap2 eduardo start This is a check-in, not an import... Weird that is says No conflicts though. What have you done before that (give us the output of 'ls'), and what is the exact output of cvs? Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: What's the best way to work with branches.
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Kevin Drapel Gesendet: dinsdag 5 oktober 2004 23:08 Betreff: What's the best way to work with branches. I work on a project with another admin. We have a set of developers but we don't fully trust their work and we want to moderate their code. From the main trunk, I created a branch called unstable, we want to merge the changes made by developers into this branch (which will be further merged back into the main trunk). I also created a branch per developer, each developer works on his own branch and he's supposed to update his branch from the unstable branch (my question is about this problem). Get rid of the branches. Really! Just have them write access on the trunk, and branch off releases that May need fixing or packaging away from the development. Multi-user developments normally happen on the main trunk, while specific Developments can be branched off until the code is stable enough to go With the main development. (E.g. you have a multi platform app and somebody needs to update the Win32 Specific code very much, and he touches a lot of the stuff in the portable Section too, cerate a branch for him and have him do his work.) (E.g. you have an application that is close to being released. Create a Branch, dedicate some people to the branch, have them make the release Feature and function stable, package the thing, ship it, and fix bugs On that branch for later merging to the trunk.) Even on a non branched tree, you can do code reviews or automated tests per (set of) commit, if you really don't trust your developers. But then again, that is an organizational and psychological question. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: problems with Visual C# projects
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Naveen M Gesendet: woensdag 6 oktober 2004 7:59 Betreff: problems with Visual C# projects I would like to manage my Visual C# projects in a repository. When I tried putting a project in the repository, it seems that it is un-successful. Try to be more specific. What cvs client version, server version, way of contacting the server? Just doing a cvs commit without anything else is the same as drinking Water from an empty cup. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: Is there any risk in installing and using CVS Binaries?
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Paras jain Gesendet: woensdag 6 oktober 2004 8:21 Betreff: Is there any risk in installing and using CVS Binaries? Binary distributions of CVS are released as is. Binaries are provided by users and are distributed by cvshome.org without review. cvshome.org is distributing these binary executables as a service to the CVS community, and takes no responsibility for their contents. Above is the content at CVS home site. I have installed Red HAT LINUX ES 3 and it is containing CVS version 1.11.2. I would like to upgrade to stable version 1.11.17. For that I would like to download the Binaries? Is there any problem in using the binaries? I do not like to build the CVS because of my thinking that it is difficult!! 1: Since the people at cvshome.org are not providing binaries, they are not responsible for binaries that could contain virusses or trojan horses. That's basically what the disclaimer says. 2: It all boils down to: $ configure $ make $ make test $ su -c 'make install' Read the approriate documentation and do what it says. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: CVS setting up
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Vipin Chandran Gesendet: woensdag 6 oktober 2004 8:44 Betreff: CVS setting up Hi, I am new to the cvs concept.. Now pls tell me where to start I have a windows client - server system in our office. I have installed cvsnt in the server .. now pls tell me how to proceed .. the workstations should be able to simultaneously work on the project files in the server .. can u tell me the procedure to set it up and some links to know all the stuff Like we should do your job? Read the manuals. Cederqvist is a good starting point, and Eventually CvsNT has some documents as well. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: Do we need lot of repositories?
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Paras jain Gesendet: maandag 4 oktober 2004 7:14 Betreff: Do we need lot of repositories? We are handling the projects in two groups one is in high level language (Delphi, VC++..) and one in Assembly language. In each group we are several developers with several projects. There can be two possibilities to create repositories in CVS: Another option: 1) One repository with Unix mapped user ids so that file permissions will restrict access Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: generating logs to mail out from a repository, not checked out code?
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Carl Brewer Gesendet: maandag 4 oktober 2004 9:15 Betreff: generating logs to mail out from a repository, not checked out code? Hello, I'm trying to get an email summary of changes to an entire repository. I have a repository : /home/scvs/repository, Look at the loginfo hook. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: waiting for lock message on cvs
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Paul Sander Gesendet: dinsdag 28 september 2004 16:27 Betreff: Re: waiting for lock message on cvs The other thing you should do is avoid using kill -9 as your first resort to get rid of something you don't want. It's a Especially with vim and cvs... Poor tools ;) You might want to read some manuals as well as to how to get out of vim, once this scary editor pops up... Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: Problems to tag a directory named .libs!
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Goran Gesendet: vrijdag 24 september 2004 12:00 Betreff: Problems to tag a directory named .libs! In my repository I got a directory starting with a dot(.). When I want to make a tag i get problems with that directory. The error message i get when making a tag from cervicia is the following: cvs tag -b v1_1_0 '.' cvs tag: in directory apps/handler/src/lib/.libs: cvs [tag aborted]: There is no version here; do 'cvs checkout' first I checked the manual(s) and it seems CVS has no problem with a . in the directory name. It looks like, according to the manual, that if you did not check out a directory from the repository, CVS might come back with a message There is no version here; do 'cvs checkout' first. Also, in a different set of manuals, I found that .libs is generated by one of the GNU autotools... Cheers, Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: CVS - brief summary
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Andrew Black (delete obvious bit) Gesendet: dinsdag 7 september 2004 7:05 Is there a command that can give a brief list of what changes you Sandbox is from repository (ideally one line per file). cvs -n upd Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: cvs web page management
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Robert Singleton Gesendet: vrijdag 3 september 2004 19:26 cvs [update aborted]: there is no version here; run 'cvs checkout' first As it says, there is no checked out version yet, so an update does not really make sense. Guus --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
AW: Help Required
Amit, Please do post your modules file, state cvs versions used (client and server) and have a glance at your project structure... This all will help pinpoint the right answer. (Best guess for now, is that your modules file contains looped references... *grin*) Cheerio, Guus -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Amit Sharma (SCM) Gesendet: woensdag 26 februari 2003 9:11 An: '[EMAIL PROTECTED]' Betreff: Help Required Hi All, While getting code from CVS Server (Suse Linux Enterprise Edition 7.0) using wincvs I am getting the following error cvs server: module `QPS/ALLPRODS_CDFJM' in modules file contains infinite loop cvs server: cannot open current directory: Too many open files cvs [checkout aborted]: end of file from server (consult above messages if any) Any help in this regard would be appreciable. Regrads, Amit ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.455 / Virus Database: 255 - Release Date: 13/02/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.455 / Virus Database: 255 - Release Date: 13/02/2003 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Feedback, idea about improvement
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Ashley Subject: Feedback, idea about improvement When I'm using cvs to checkin using a LAN in an office environment, I don't always bother to enter a comment. My editor pops up, and I just delete the first blank line, then save the file. All this takes less than a second. Even more speed would be gained, when you would use $ cvs ci -m "" -m gives checkin a message to use, so it doesn't even invoke you favorite vi. Just my 0.03$ :) Guus ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: scripts run as who?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Largent, Jim Subject: scripts run as who? I have a perl script that executes out of the taginfo file. I need to set up the default include path for library modules (they're in a non-standard directory). When I access the repository remotely, I get an error because it can't file the library path. When I log on directly to the box (with an account that has the PERLLIB environment variable set) the script runs fine. My questions is when the remote user connects where/how is the environment set up? I'm guessing that the inetd.conf file specifies the CVS runs as the user destined as the 'local user' in the repository's password. This can be the same user as the one who's account your doing your tests with, or any 'ghost' user that doesn't have a specific login that sets the PERLLIB. Please check your password file, and setup the env of that user correctly, or make the PERLLIB setting standard for all users, or, even better, incorporate the perl scripts in a standard place under perl or under /usr/bin. Guus ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Graphical CVS branches analizer
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Luciano Baretta Mandryk Sent: Friday, January 19, 2001 8:05 PM Does anybody know of a tool that analizes CVS logs and builds a graphical representation of a project's "branch tree"? If not, I'd What about WinCVS? I don't know whether thingies like tkCVS do this, but you can always check on http://www.cvsgui.org?. Guus ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: A Question
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Frode Nilsen Sent: Wednesday, January 10, 2001 4:08 PM Agreed that this sound like a "lame" strategy, but aren't this what import is supposed solve ? Nope. Import is there to track of *third* party software, not of updates from geographically distant people working on the same sources. Guus"wrj)b b'~/!f ?+-w)
RE: file access
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, January 10, 2001 9:06 PM Correct me if I'm wrong, but if my default group is developers. But I am also a member of the group admin. If I checkout and edit a file that belongs to the group admin and check the file in to the repository again. The file will not longer belong to the group admin but instead to my default group developers. Is this correct behavior or is something very wrong?? There is, of course, always the possibility to think before you do. Which, in this context means: Since I now want to work on project A, I'll have to switch to the group of project A. Hence 'newgrp - project_a_group' does the trick. Guus"wrj)b b'~/!f ?+-w)
RE: Getting list of files in a module
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of TC You must checkout cvsroot, edit the modules file,,then commit then you can checkout any of the modules that you have listed in the modules file see pg 117 in the pdf manual Good answer. Unfortunately, the question asked doesn't fit it, though. Try reading the questin first, and then answer it. -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] I've just installed CVS 1.11. I'm trying to get a list of the files in a module without having checked the files in that module out, by running: cvs -n checkout myprog In response I get: cvs [server aborted]: there is no version here; run 'cvs checkout' first. This seems a bit of a "catch 22"! Yes it is :( Unfortunately, there is no easy way to do this. Best throw is to have a user at the box that holds the repository do an ls -R and have that sent to you. Cheers, guus '~/²f¢)à+-"wèrû ê+m§ÿæj)`ê+ùYùb²Ø§~âú ¾
RE: cvs log and revision range
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Laine Stump [EMAIL PROTECTED] (Larry Jones) writes: "Between" really isn't meaningful for revisions on different branches. Sure it is, you just have to think about it a bit differently. It could be displayed as a set of "reverse logs" going from the first tag backwards to the common branchpoint, then "forward logs" to the 2nd HEAD: 1.4 BRANCH1_HEAD: 1.2.1.1 BRANCH2_HEAD: 1.3.1.1 What's the common branchpoint for BRANCH2_HEAD and BRANCH1_HEAD? There isn't any... untill we hit 1.1(.1.1)... Which is too way back in the past. Guus '~/²f¢)à+-"wèrû ê+m§ÿæj)`ê+ùYùb²Ø§~âú ¾
RE: Cvs of system administration files again
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Les Mikesell
I see there was some discussion on this list earlier about using cvs
with unix system configuration file but no real resolution
or examples
of anyone doing it. I'd like to go a step beyond a single instance
and would listen to any advice about how to set it up or if it is
a good idea in the first place. Most of my machines are running
RedHat Linux which puts all the config files under /etc, so to get
Best way for this would be a network bootable setup that changes only
the bits it needs to change... (Like IP-Addr)
Also, there are an assortment of config files for routers and
similar equipment that should be managed in a similar way, but
of course those devices can't participate directly in client/server
cvs access so the files need to live under a tftp directory
somewhere.
Is there some standard way to handle a case where you want a set of
branches checked out at the same time in more or less the same place?
cvs co -d my_mod_branch1 -r branch1 my_mod
cvs co -d my_mod_branch2 -r branch2 my_mod
Just my $0.02,
Guusú ¾ÉX§X¬´ß¡Ëì{¨®m¶ÿ¨¥{¨®æj)fjåËbú?wèrû
Bug in client.c?
Hey, I just checked out the latest on cvs.cyclic.com repository and find that cvs is not linkable: client.o: In function `connect_to_pserver': /home/gleeuw/Work/OpenSource/ccvs-compile/src/client.c:3850: undefined reference to `CVSroot_port' Do we have a patch for this or pointers as to waht to change? (Assuming small change :) Cheers, Guus ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Bug in client.c?
From: Larry Jones [mailto:[EMAIL PROTECTED]]
Guus Leeuw writes:
I just checked out the latest on cvs.cyclic.com repository and
find that cvs is not linkable:
client.o: In function `connect_to_pserver':
/home/gleeuw/Work/OpenSource/ccvs-compile/src/client.c:3850:
undefined
reference to `CVSroot_port'
there must be something wrong with your checkout. CVSroot_port is
declared on line 385 of src/cvs.h, and the reference in
client.c is on
line 3833, so there's definitely something wrong. client.c should be
revision 1.288 and cvs.h should be 1.206 -- what do you have?
gleeuw@germany:~/Work/OpenSource/ccvs-cyclic/src grep -n CVSroot_port
cvs.h
385:extern int CVSroot_port;/* the port or zero if method == local */
gleeuw@germany:~/Work/OpenSource/ccvs-cyclic/src grep -n CVSroot_port
client.c
3833:port_number = CVSroot_port ? CVSroot_port : get_port_number
("CVS_CLIENT_PORT", "cvspserver", CVS_AUTH_PORT);
4045:port = CVSroot_port ? CVSroot_port : get_port_number
("CVS_CLIENT_PORT", "cvs", CVS_PORT);
gleeuw@germany:~/Work/OpenSource/ccvs-cyclic/src
And from WinCVS to access the repository at cvs.cyclic.com:
cvs -q status -v cvs.h (in directory F:\Work\cyclic_ccvs\src\)
===
File: cvs.h Status: Up-to-date
Working revision:1.206
Repository revision: 1.206 /home2/cvsroot/ccvs/src/cvs.h,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
[ snipped ]
cvs -q status -v client.c (in directory F:\Work\cyclic_ccvs\src\)
===
File: client.c Status: Up-to-date
Working revision:1.288
Repository revision: 1.288 /home2/cvsroot/ccvs/src/client.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
[ snipped ]
I guess I have all you mentioned...
Platform is Linux SuSE 6.4.
Cheers,
Guus
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Bug in client.c?
From: Larry Jones [mailto:[EMAIL PROTECTED]] Rich Salz writes (quoting me): there must be something wrong with your checkout. CVSroot_port is declared on line 385 of src/cvs.h Right, but is it defined anywhere -- i.e., in some C file w/o the "extern" ? Yes, src/root.c. But he was getting a compile error, not a link error. Larry, I had a link error. gcc is smart enough to say where the link stems from, but it started saying: "client.o: In function `connect_to_pserver':" Anyways, saying that it was defined in root.c, I checked on my check out from cyclic.cvs.com and found I had version 1.41, without CVSroot_port. An update reveiled that there was a 1.42... Guess the network hicked up between my PC and cvs.cyclic.com on the first update I did. Now, it compiles and links :) Guus ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Problem with fresh 1.11.1
Heya, quick question on Linux SuSE 6.4 with CVS 1.11: If I get the latest from ftp.cvshome.org, and issue following: $ tar zxvf cvs-1.11.tar.gz $ cd cvs-1.11 $ ./configure --enable-client --enable-server $ make $ make check $ su Password: $ make install ^D $ cd $ cd Work/wps $ cvs -nq upd [server aborted]: cannot create_adm_p in /tmp/cvs-serv12343 $ Shrug. Looking at the code, this error is only thrown out in the server.c where it tries to setup the temporary structure on /tmp It can create /tmp/cvs-serv12343, /tmp/cvs-serv12343/CVS, /tmp/cvs-serv12343/wps, and /tmp/cvs-serv12343/wps/CVS but after that it dies. Loads of free diskspace and inodes. -f -T in inetd.conf don't help. Setup is a pserver running as root but then changing to cvsuser. $CVSROOT=:pserver:[EMAIL PROTECTED]:/home/CodeRepository. Now, I'm at a complete loss, thought I saw this being mentioned somewhere but cannot find it back. Thing as well is, that I have at home a SuSE Linux 6.4 as well, whereby all works fine there. Can anybody help / advise / open my eyes? Thanks. Dipl.-Inf. Guus Leeuw jr. Mynatt Leeuw Consultancy GmbH Voigtelstr. 10 50933 Köln mailto:[EMAIL PROTECTED] Tel: 0175-2424950 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Moving repository (slowly)
-Original Message- From: [EMAIL PROTECTED] Furthermore, if I were in your shoes, I would shutdown client availability--temporarily removing the inetd.conf entry (one of many ways)--while making changes, and enabling it after it is done. The changes will be quick, but why not close the window? But I come from the Paranoid Sysadmin school of thought... Besides, try hiding the CVS PServer behind a unique DNS, even if that is not the single service on the machine. If you do this, you will never ever again happen to have a window where nobody can access the Repository, and / or have to change their SandBox. Just my $0.02, Guus ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Cvs diff with multiples files in multiples directories
-Original Message- From: Fabrice Gautier [mailto:[EMAIL PROTECTED]] cvs -q diff -u -r mypatch.txt You should read the Cederqvist manual. Try the command rdiff and you probably want to forget about the -u option (unidiff, which is not supported by old patch programs). Guus
RE: Keyword substitution in binary files?
Hey Anders, I have a tool that is capable of performing the substitution, but I know of no way to get the (new) revision number before the file is actually committed. You could run a 'cvs log thefile.doc' prior to substituting and comitting the doc. Of course, you have to make sure that no one else is doing a commit to the same file while you do it, because the log output might be outdated at the time the commit is performed. This though can be done using the lock command (if you really need it). Guus
RE: recovery of erroneously committed file
I have accidentally checked in a Microsoft Word format file as a normal text file, instead of binary. Can I recover this file in its original form, or is it permanently trashed? Two options come to mind: 1) If your file was the first version, get someone to delete the corresponding Repository file, go back to the drawing board and start from scratch. 2) If not, move the file out of your local sandbox, update the previous version (the one just before you comittied), put your copy over it, execute cvs admin -kb on your local file and commit it. Guus
RE: program option limitations on client machine
From: David Martin [mailto:[EMAIL PROTECTED]] Sent: Monday, September 11, 2000 9:10 PM Can anyone suggest what's a good way to get the functionality I want? You would have to wrap CVS on the client side in a script, doing the steps you mentioned. GUus
RE: How can I create separate submodules?
-Original Message- From: Greg Noel [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 10, 2000 10:06 AM Let's say I have a module M and several submodules, A, B, and C. What I'd like to do is be able to do a CVS checkout like this: cvs -d ... checkout M # Just the base module cvs -d ... checkout M B # The base plus one submodule cvs -d ... checkout M A C # The base plus two submodules The trick is that I'd like A to be checked out as M/foo/bar/A (within the base module's tree), B is checked out as M/foo/baz/B, and C checked out as M/bletch/C. What I would suggest, but I might miss the bullseye way, is that you include A B and C just as toplevel modules, like M, and your build system (make or some such) takes care of the moves... Or even, your build system, detecting A is not there, but needed, checks it out. Just my $0.02, Guus
RE: How can I create separate submodules?
From: Greg Noel [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 10, 2000 10:45 AM On Sun, 10 Sep 2000 10:09:09 +0200 Guus Leeuw [EMAIL PROTECTED] wrote: Or even, your build system, detecting A is not there, but needed, checks it out. Actually, the reverse is true. If the build system detects that the submodule has been checked out, it automatically enables the code that uses it. The reverse? H So it's up to the developer building M for A, B, or C? In that case, you cannot do more then 1) Ask at the beginning of the build, what subs to include, if none have been detected (if this is a valid rule :) 2) Move the subs (A, B, C) when they are detected to the correct place and build away. Anyone other views? Guus
RE: How can I create separate submodules?
From: Greg Noel [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 10, 2000 12:03 PM I keep hoping there's a magical solution. I don't have a place to test (other than the live system, and I'm loathe to break it), but I wonder about some lines in the modules file like this: A -a foo/bar/A foo/bar/A A That is, A acts as if foo/bar/A had been specified, but foo/bar/A fetches its files from A. (Can a module name have slashes?) I'm not too sure about these. There's also a mysterious '-d dir' option for specifying a module. Does this identify the server directory (useless for my purposes) or the client directory (which is probably very close to what I'm trying to do)? -d specifies (after co) the target directory on the client, so you could say: cvs co -d M/foo/bar/A A Cheers, Guus
RE: How to enable email for commit log messages
Muhammad Shakeel wrote once: I am using cvs 1.10 on Solaris 7. How to enable email to a group so that the cvs commit log messages also sent through email to a group. Couple of possibilities. 1) Use your MDA to send to a group and have it know the members of that group 2) Setup a group in /etc/aliases and send to that. MTA should be able to figure that out 3) create a script that sends the message to multiple recipients. Guus
AW: RCS_checkout: Assertion
Mark Derricutt [mailto:[EMAIL PROTECTED]] once wrote: So I need to merge branch_level2 into branch_level1 first, THEN branch_level1 into HEAD? That is the usual approach. Have a look in Chapter "Branching and merging" in the Cederqvist Manual. Guus
RE: CVS for Lawyers?
-Original Message- From: Duncan Kinder [mailto:[EMAIL PROTECTED]] So it would work for html? Oh Yes :) I've been at a site where they used it for MS Word Docs as well. The CVS Admin once in a while went ahead and removed revisions from the files, just to make the repository not too big. That worked witout problems. Just my $0.02, Guus
RE: how to restore an old version of a file?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] how can i restore the old version? $ cvs upd -r1.2 -p file file $ cvs commit Guus
RE: cvs [login aborted]: unrecognized auth response from 10.5.0.30
-Original Message- From: Jimmy Lavoie [mailto:[EMAIL PROTECTED]] OK, I've removed the "\" and it's working now. Thank you. It's a shame that the "\" was in the documentation. Which documentation? Guus
RE: error when using password authentication
-Original Message- From: Goeran Zaengerlein [mailto:[EMAIL PROTECTED]] So I added the following line to inetd.conf: cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/usr/cvsroot pserver [all on one line] Look at the archive on eGroups.com in this mailing list. This really is a FAQ. Guus
RE: cvs [login aborted]: unrecognized auth response from 10.5.0.30
-Original Message- From: Jimmy Lavoie [mailto:[EMAIL PROTECTED]] What is wrong with that? Which CVS Version? Guus
RE: cvs [login aborted]: unrecognized auth response from 10.5.0.30
-Original Message- From: Jimmy Lavoie [mailto:[EMAIL PROTECTED]] This is the line I add in /etc/inetd.conf cvspserver stream tcp nowait root /usr/bin/cvs \ cvs -f --allow-root=/src/cvs pserver Hmmm :) Should have spotted that earlier. Remove the \ and join both lines so that you and up with 1 line. Cheers, Guus
RE: why is CVS currently unavailable for Solaris?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] I went to the cvshome.org web site hoping to download CVS or Solaris 2.6 and instead of a link all it had was that this version is currently unavailable. What's up with that? Is there another site I can download it from? I don't know what the maintainers are up to, but you still can download the sources, and go from there. Guus
Bug in WinCVS?
Heya, I've used winCVS (1.1b14) for quite a time now, and never seen anything like this: WINCVS caused an invalid page fault in module MFC42.DLL at 0137:6c375089. Registers: EAX= CS=0137 EIP=6c375089 EFLGS=00010216 EBX=0046e3c8 SS=013f ESP=006df388 EBP= ECX= DS=013f ESI=006f5648 FS=0fa7 EDX=6c411758 ES=013f EDI=0001 GS= Bytes at CS:EIP: 8b 41 3c 85 c0 0f 85 32 93 05 00 ff 71 20 ff 15 Stack dump: 0040ff6b 006f5648 0bb8 006df41c 0040fef0 6c37206f 0001 008064e0 006f5648 006f5648 005b0160 0003 006df428 8496 005b0160 Rest of the box is working fine, so it seems. Alright, I know my box crashed because of a thunder storm, but even installing WinCVS a new, doesn't make the thing go away. Any hints? (I'm not that much of a Windows Hacker :)) What could I do? Guus
RE: CVS-Tree
From: Rohit Desai [mailto:[EMAIL PROTECTED]] Is there any tool/script around that would display the version tree in a format as follows : You might want to check out WinCVS. It comes with a graphing function. If you don't have a Windows box, you still might want to get the sources and see how they parse the cvs log (or is it stat?) output Cheers, Guus
RE: $CVSROOT/CVSROOT/cvsignore - not working ?!
From: Guus Leeuw [mailto:[EMAIL PROTECTED]] From: Larry Jones [mailto:[EMAIL PROTECTED]] (Of course, you need to preserve backwards compatibility, so the client still has to behave the old way if the server doesn't support the new request to get CVSROOT/cvsignore, and the server still has to support the Questionable request for old clients.) Bad Thing (tm) Like your footnote said: the middle ground (backwards compatibility) is for sissy weasels... *laugh* I'll see whether that will be possible... Okay. Bit more investigation has been done. Found sofar a good place to get the server's $CVSROOT/CVSROOT/cvsignore: start_server() in client.c right after we do connect_to_?server(). One thing though, Larry (*grin*), and that is: what about :ext: protocols where to user is supposed to have a login on the server? If the server now only sends the Repository's cvsignore, whatever the user has setup in his $HOME/.cvsignore will not be send to the client. Is this wanted? Or should I rather go and make only changes for GSSAPI, KERBEROS, and PSERVER? What is the opinion on this? Cheers, Guus
RE: $CVSROOT/CVSROOT/cvsignore - not working ?!
[ Prescript This is a bit long an email, but explains pretty much what I think is the right way at the moment. ] From: Larry Jones [mailto:[EMAIL PROTECTED]] Guus Leeuw writes: Found sofar a good place to get the server's $CVSROOT/CVSROOT/cvsignore: start_server() in client.c right after we do connect_to_?server(). I'm not sure that's safe -- I suspect that it's better to do it in ign_setup() right where it processes CVSROOT/cvsignore in the local case. Although the current CVS client never does more than Fair. Possible as well, but what strikes here is: How does the client ask for the server's CVSROOT/cvsignore file? If new clients should work with old servers, they can't ask, because the old server would bail out: Unknown Question or some such. It will behave weird at least. What if the case is: New server with old client? Problem: the client has to explicitly ask for it, otherwise the send of the CVSROOT/ignore will f*ck up the first answer the old client expects: Valid-requests x y etc. That means: in the context of OC NS, the server cannot send anything. Why? Because it was not asked. in the context of NC OS, the the client cannot ask, because the server doesn't understand, and sends an error. OC OS is all fair: doesn't work anyways :) NC NS is all fair: NC asks, NS sends. Well..., if NC asks, and OS sends an error: we can deal with that. No problem that the server didn't understand us we're apparently newer in the NC than the OS is. NC OS is all fair: we can deal with errors internally. OC NS: No problem, the new server doesn't work on any (.)cvsignore file anymore, so it only sends if asked. Since it is not asked, all is well. Recapture: OC OS is all fair: doesn't work anyways :) OC NS is all fair: the server would not send cvsignore. NC NS is all fair: NC asks, NS sends. NC OS is all fair: we can deal with errors internally. Okay. (OC = Old Client, NS = New Server, etc.). So we can release it anytime we want. Now, the ign_setup will then be completely ignored by the server. The code will not exist anymore in this detail (for the server). The server merely pipes the data in CVSROOT/cvsignore when asked for it. Okay, after three days of investigation, I now know pretty much how I could do it then. Let's start coding :) (Ooops I'll first have to figure out how c/s talk to eachother... Lemme see, whether I can *grin*) One thing though, Larry (*grin*), and that is: what about :ext: protocols where to user is supposed to have a login on the server? If the server now only sends the Repository's cvsignore, whatever the user has setup in his $HOME/.cvsignore will not be send to the client. Is this wanted? Or should I rather go and make only changes for GSSAPI, KERBEROS, and PSERVER? I think ~/.cvsignore on the server should be ignored. Cool, fits the above, I guess :) Lemme start rolling :) Cya, Guus
RE: CVS permissions
From: Larry Jones [mailto:[EMAIL PROTECTED]] Stephen Rasku writes: In this case, I would need to manually add every user to the CVSROOT/passwd file. I assume that it would look I have a patch that I've been sitting on that allows wildcards in CVSROOT/passwd. That would allow you to just do: *:ULtgRLXo7NRxs:cvsuser which would let absolutely anyone use CVS provided they know the password. It would also let you do things like: This one, at least sounds great. Gets rid of the extra administration. Although, it sounds kinda hard with the cvspasswd utility not included in the contrib... Can we add it? *:*:cvsuser to let only authorized system users use CVS using their system passwords. Hmmm I'm not too sure whether this is a Good Thing (tm). But then again, you don't have to use the feature :) So, I'ld suggest to include it anyways. As long as the pserver section talks about it, it should be fine (assuming it doesn't break old the structure *evilgrin*). Guus
RE: $CVSROOT/CVSROOT/cvsignore - not working ?!
From: Larry Jones [mailto:[EMAIL PROTECTED]] It's more complicated than that -- most of the individual cvs commands also call ign_setup(), even when running in server mode. That's what I detected in the meantime as well. I think the right thing to do, is to have all of the ignore processing take place on the client side (asking the server for its CVSROOT/cvsignore and including it at the appropriate place in the processing) and have the client tell the server to ignore nothing. In that case, the client would never send any Questionable requests to the server and so serve_questionable() would never be called. Yes Yes Yes :))) (Of course, you need to preserve backwards compatibility, so the client still has to behave the old way if the server doesn't support the new request to get CVSROOT/cvsignore, and the server still has to support the Questionable request for old clients.) Bad Thing (tm) Like your footnote said: the middle ground (backwards compatibility) is for sissy weasels... *laugh* I'll see whether that will be possible... (How am I going to sanity.sh backwards compat??? *grin*) Guus
RE: Update command
From: Steve Cowling [mailto:[EMAIL PROTECTED]] When you do an update using winCVS what does the "p file name" message mean that come up in blue text in the status window. I guess it means preserved but I can't confirm it. "P file" means, the server sends or will send (*) a patch for file. (*) will send: if cvs -n upd has been called (a query update ala WinCVS :) Guus
RE: Repository link
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] I am running cvs-1.10.8 on a linux server(debian). Our main file server is NT. Is it possible to link the repository to our file server, and just have the linux server 'run' cvs. I am not sure if cvs will complain about this. My concern is to ensure cvs runs smoothly, while maintaining the best mechanism for backups(as our NT File server has a nice RAID setup plus a good tape backup system). I realize I can just backup the cvs repository directly from the linux machine, but I prefer using the NT server. All input is appreciated, As long as your clients to the repository are *always* the same type (either Un*x, or Windows(/Mac ?)), you should be safe with this option. But, I guess, it might be slow for network traffic... ;] And it does not necessarily support the future :) What I would try to find out, is whether you can have the NT box mount the Repository volume once a night, and just back that up as well... This would give you the chance of having a single machine involved in the CVS Server Part. Just my $0.02 Guus
RE: Wincvs
From: Annette Waters [mailto:[EMAIL PROTECTED]] I am trying to setup Wincvs using pserver to Linux cvs repo. I'm getting the error: cvs [login aborted]: connect to linux1:0 failed: Can't assign requested address Seems like your Windows box cannot resolve the $CVSROOT settings... Could you give us whatever is in the CVSROOT text field under Ctrl+F1 in WinCVS? Guus
RE: $CVSROOT/CVSROOT/cvsignore - not working ?!
Allright. I'll hack it in my local version, stuff up some test cases, and see where it takes me :) Hmm... the server goes ahead in server.c and calls ign_setup() from serve_questionable. I mean, by calling this function, the Server in itself behaves *way* different from local only CVS... I think, right now, it cannot even as much as care about the things ign_setup does. What it should care about, really, is only the $CVSROOT/CVSROOT/.cvsignore. Larry, any opinions? *grin* Hmm, are there a lot of people using real accounts on the CVS Server that can override the .cvsignore from the Client? Meaning: Assume, I have an account on my client ([EMAIL PROTECTED]) and on my server ([EMAIL PROTECTED]). In both there is a .cvsignore. Assume, on client, I am hacking on the module my_proj. I add a file that is called foo_bar.c. Assume, on the server, I was testing and had a $HOME/.cvsignore that has foo_bar* as its only entry. If I now cvs upd my_proj on client, the server goes ahead and ignores foo_bar.c, although I would like to have it included... So the strategy would be to remove this precious call to ign_setup() from within serve_questionable() and have the client ign_setup somehow detect, that the server might have something for him in the (!) $CVSROOT/CVSROOT/.cvsignore list only (!). Is this in line with what you might have in mind? Cheers, Guus
RE: Wincvs
From: Annette Waters [mailto:[EMAIL PROTECTED]] :pserver:cvs_user@linux1:/usr/local/newrepos Sounds fair. Is your box pingable by the name linux1? Try a 'telnet linux1 2401' on your MS-DOS box. As soon as the telnet "hangs" type in just about something (with a return at the end (!) *grin*, you're apt to break the login protocol, and cvs pserver will tell you this. If this you get something like "bad auth protocol start: your text" cvs pserver is all fine, $CVSROOT is okay :) I installed WINcvs1.0 and was able to login.. I could not check out a module through the gui - had to check it out using the command line. Try WinCVS 1.1b14 with cvs 1.10 (of course, you need to have the cvs 1.10 then on the Linux machine...) I just opened 1.1 and the module I checked out under 1.0 is there (I used the same /HOME/folder) *blurr* What do you mean with 1.1 and 1.0? Hmm... Revisions of a file? or WinCVS Version? or which *grin* ? Hmmm... What Linux are you running? What is the entry in the Linux's etc/inetd.conf? Guus [ rest omitted for brevity ]
RE: Wincvs
From: Annette Waters [mailto:[EMAIL PROTECTED]] I'm running Concurrent Versions System (CVS) 1.10.6 (client/server) on my Linux box Don't use 1.10.6. The pserver is broken in that version. Get a copy of 1.10.8 and get that installed on your linux box. Then use WinCVS 1.1 again. This should sort out all problems you are having. Guus
RE: $CVSROOT/CVSROOT/cvsignore - not working ?!
From: Larry Jones [mailto:[EMAIL PROTECTED]] Guus Leeuw writes: Wouldn't this be something nice to have for 1.11 (If it comes *grin*)? What would be the strategy to stuff this in? New command, or option to commands? Larry, tell me :))) Neither, just changing the existing code to do it right. I haven't thought about what the consequences of doing that would be, though. Well, apparently that makes for the Server to overwrite Client non-ignores, meaning that it becomes a Repository issue whether some CVS Admin lets in file like *.o *~ etc. This, IMO, is a Good Thing (TM), as local CVS does it same way. Really, either we have both Local and Client/Server act the same (above scheme), or we get rid of the Repository .cvsignore file completely... Bet, the latter is not wanted by the people. (Or is it???) Guus
RE: $CVSROOT/CVSROOT/cvsignore - not working ?!
From: Larry Jones [mailto:[EMAIL PROTECTED]] Not quite -- the way it works locally (which is the usual benchmark for what "do it right" means) is that you start with the default ignore list, then you apply the repository's cvsignore (which, in c/s mode requires getting it from the server which the client currently doesn't do), then you apply the user's ~/.cvsignore, then you apply the -I option(s) from the command line (if the command has a -I option), and finally you apply the .cvsignore file from the current directory. Allright. I'll hack it in my local version, stuff up some test cases, and see where it takes me :) Guus
RE: $CVSROOT/CVSROOT/cvsignore - not working ?!
From: Larry Jones [mailto:[EMAIL PROTECTED]] $CVSROOT/CVSROOT/cvsignore doesn't work quite right in client/server mode. Unfortunately, there is currently no way for the client to get the contents of $CVSROOT/CVSROOT/cvsignore from the server, so the server's ignore list can only augment the client's ignore list, not override it. Wouldn't this be something nice to have for 1.11 (If it comes *grin*)? What would be the strategy to stuff this in? New command, or option to commands? Larry, tell me :))) Guus
RE: Does CVS work with unicode files?
From: ccyf [mailto:[EMAIL PROTECTED]] If files contain non-ascii characters, does cvs commands like diff still work? Nope. There are two possible ways of dealing with these: 1. Just check them in as ASCII, and possibly get them corrupted... as CVS doesn't understand UNICODE 2. cvs add -kb unicode-file them, so that CVS thinks they're binary and leaves them alone (doesn't try to do *anything* with the contents of the file. Cheers, Guus
