Re: CVS vs ClearCase, was RE: cvs -n update vs cvs diff
--- Johnson, Susan [EMAIL PROTECTED] wrote: I'm used to ClearCase, where a person worked within a dynamic view and you could build, label (tag), branch, merge and do everything within the same workspace. How does CVS differ from that model? This is pretty much how I use CVS. One big difference between ClearCase's dynamic views and CVS is that, for files that are not checked out (ClearCase meaning), when someone checks it in, you'll see the changes automatically by default. CVS's working directories work more like ClearCase's sandboxes (I think this is the right term). Personally, I never liked the default dynamic view behaviour since it meant less control over what I'm working with (eg someone can break my build at an inconvenient time). At one point, I toyed around with the idea of changing the config spec so that LATEST meant 'now' (ClearCase meaning). Doing so would've given me the benefits of dynamic views (eg file system access to the repo) with the benefits of static (I like this terminology better) views (eg control over what's in my working directory). HTH, Noel __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging from vendor-branch to branch
On Tue, Oct 22, 2002 at 08:28:43PM -0400, Greg A. Woods wrote: In effect, that after the import a user checking out from the branch might get files from the newer vendor version? No, that's one thing that shouldn't happen. Indeed that's part of the problem though -- after an import and merge then the local branch will still be stuck with base revisions of locally un-modified files at the pre-import level and those files will explicitly have to have their new vendor revisions merged to the branch. I tought that the procedure could be carried out like this. Before importing the new vendor version (say R2, while the previously imported one was R1), ask the developers to commit everything. Then you create a normal branch: cvs rtag VENDOR_R2_PREMERGE module cvs rtag -b -r VENDOR_R2_PREMERGE VENDOR_R2_MERGE module You ask the developers to work with the VENDOR_R2_MERGE branch, by checking out their sources like this: cvs co -r VENDOR_R2_MERGE module or sub-module You procceed with the import cvs import -m Imported VENDOR verion R2 module VENDOR VENDOR_R2 You merge the local changes cvs co -j VENDOR_R1 -j VENDOR_R2 module You resolve the confilicts, test the new sources, and generaly make sure that everything is stable. Then commit your changes. Several commits may be necesairy since the conflict resolution may take some time. No problem though since the rest of the developers are safely isolated in the VENDOR_R2_MERGE branch). When you have finished with the conflict resolution and tests you tag the trunk accordingly cvs rtag VENDOR_R2_MERGED Then you ask your developers to commit everything (in the VENDOR_R2_MERGE branch) and then to merge the branch back to the trunk (each developer his own submodule). cvs co -j VENDOR_R2_MERGE sub-module They will also (the developers) have to resolve the conflicts but there shouldn't be many since a few changes would have been made since the branch. As you can understand the idea is to make a branch that isolates the developers durring the turbulent meging period. Do you see any drawbacks with this approach? /npat -- flowchart, n.: The innumerate misleading the illiterate. A thousand pictures is worth ten lines of code. -- Stan Kelly-Bootle ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
file conflicts 'move away'
Hi, I'm working on several machines on the same project. One of them is my home machine, which does not have access to the CVS server. That means I regularly zip (or tar) all the relevant files, work on them at home, unzip the new files at work, and then want to synchronise the archive. This usually works, except when e.g. I unzipped the new files on 2 'work machines', and then synchronised the CVS archive on one of them. On the other I then get this type of conflict: $ cvs status VC/IO.dsp cvs server: move away VC/IO.dsp; it is in the way === File: IO.dspStatus: Unresolved Conflict Working revision:No entry for IO.dsp Repository revision: 1.1 /usr/local/cvsroot/parapet/PPhead/IO/VC/IO.dsp,v same happens with edited files (not only new ones), although I then get the changes usually flagged as conflicts. Of course, I totally agree with what CVS is trying to tell me and I guess clean working practices should solve my problem (although that's maybe a bit hard to do as I don't necessarily want to put my recent changes in the archive yet, but want to have all machines synchronised). However, I wonder if there's a way to force CVS to go ahead anyway whenever it gives the 'move away' message. Now I have to delete the file by hand and then call cvs update again. I'd rather pass a flag to cvs... Any suggestions? Kris Thielemans (kris.thielemans at ic.ac.uk) Imaging Research Solutions Ltd Cyclotron Building Hammersmith Hospital Du Cane Road London W12 ONN, United Kingdom web site address: http://www.irsl.org/~kris ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [checkout aborted]
Pushpa writes: MIME-Version: 1.0 Content-Type: multipart/mixed; Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! cvs server: cannot find module `acca_c1b' - ignored cvs [checkout aborted]: cannot expand modules I am getting this error when I try to check out the module using WinCVS 1.11 module c1btool Setting in WinCVS is :pserver:[EMAIL PROTECTED]:/home/cvsroot/acca_c1b That's almost certainly incorrect -- your root should be set to the *repository*, not a particular module in the repository. You want: :pserver:[EMAIL PROTECTED]:/home/cvsroot -Larry Jones OK, there IS a middle ground, but it's for sissy weasels. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Server on Novell?
(By Novell machine, I'm assuming you mean a Netware server.. :) In pserver mode, no. Using direct repository access, it should be fine. Back in the day I was a heavily involved in Netware programming, and there should be no real reason that you couldn't run the pserver on a Netware server. You'll need Codewarrior for Netware, and you'll probably need to tweak to account for the c-library oddities that Netware has. The lack of inetd (at least in the standard sense) will be an issue to cover, of course. I actually even considered doing this once a few years ago, but it's gotten backed-up in the queue these days. Just my $.02. jon * Lisa M. Doucette ([EMAIL PROTECTED]) [021022 14:48]: Hi, Does anybody know if CVS server be installed on a Novell machine? I see where servers can be set up on Windows and Linux boxes, but nowhere does it mention that it can or cannot be set up on Novell. Would you be able to provide me with an answer either way? This is very much appreciated. Thank you, Lisa Doucette ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- .Jonathan J. Miner--Division of Information Technology. |[EMAIL PROTECTED] University Of Wisconsin - Madison| |608/262.9655 Room 3149 Computer Science| `-' Oh, Lisa, you and your stories. `Bart is a vampire.' `Beer kills brain cells.' Now, let's go back to that ... building ... thingee ... where our beds and TV ... is. -- Homer Simpson Treehouse of Horror IV (495) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs [checkout aborted]
Pushpa also writes: In the server in inetd.conf file have the following line etc/inetd,conf cvspserver stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/home/cvsroot/acca_c1b pserver You also need to correct your inetd entry to not specify the particular module. You want: --allow-root=/home/cvsroot Dale Miller Pushpa writes: cvs server: cannot find module `acca_c1b' - ignored cvs [checkout aborted]: cannot expand modules I am getting this error when I try to check out the module using WinCVS 1.11 module c1btool Setting in WinCVS is :pserver:[EMAIL PROTECTED]:/home/cvsroot/acca_c1b That's almost certainly incorrect -- your root should be set to the *repository*, not a particular module in the repository. You want: :pserver:[EMAIL PROTECTED]:/home/cvsroot -Larry Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs [checkout aborted]
Can someone please tell me how to get off this mailing list? Thanks -Original Message- From: Miller Dale Contractor HQ AFWA [mailto:Dale.Miller;afwa.af.mil] Sent: Wednesday, October 23, 2002 1:28 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: cvs [checkout aborted] Pushpa also writes: In the server in inetd.conf file have the following line etc/inetd,conf cvspserver stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/home/cvsroot/acca_c1b pserver You also need to correct your inetd entry to not specify the particular module. You want: --allow-root=/home/cvsroot Dale Miller Pushpa writes: cvs server: cannot find module `acca_c1b' - ignored cvs [checkout aborted]: cannot expand modules I am getting this error when I try to check out the module using WinCVS 1.11 module c1btool Setting in WinCVS is :pserver:[EMAIL PROTECTED]:/home/cvsroot/acca_c1b That's almost certainly incorrect -- your root should be set to the *repository*, not a particular module in the repository. You want: :pserver:[EMAIL PROTECTED]:/home/cvsroot -Larry Jones ___ 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 [checkout aborted]
Can someone please tell me how to get off this mailing list? Scroll down to this link: http://mail.gnu.org/mailman/listinfo/info-cvs Then scroll down to where it mentions unsubscribe from Info-cvs. (Note that individuals may still 'cc' you on existing threads in which you may have participated) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Info about tags
Is there any way to get, via a script of something, information about the tags in a CVS-controlled tree? I want for example to answer the questions like the following: What tags exist, listed in chronological order? What are the names of the tags corresponding to vendor-branch imports, in chronological order? What tags exist in a specific branch? etc /npat ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
tag vs rtag question, was Re: Merging from vendor-branch to branch
Nick Patavalis wrote: SNIP You merge the local changes cvs co -j VENDOR_R1 -j VENDOR_R2 module You resolve the confilicts, test the new sources, and generaly make sure that everything is stable. Then commit your changes. Several commits may be necesairy since the conflict resolution may take some time. No problem though since the rest of the developers are safely isolated in the VENDOR_R2_MERGE branch). When you have finished with the conflict resolution and tests you tag the trunk accordingly cvs rtag VENDOR_R2_MERGED SNIP I have not worked with normal branches or rtag before, I have always used tag and import, so I am asking this from a 'please correct my head perspective'. If at the point the rtag is ran above the last commit of a file happened on the branch would rtag place the tag on the HEAD version of the file (what we want here, I think) or on the branch version of the file? http://www.cvshome.org/docs/manual/cvs_4.html#SEC44 http://www.cvshome.org/docs/manual/cvs_17.html#SEC153 The above pages from the manual are not real clear (to me) on what rtag tags if you do not give a -rsomthing as it is working on some (possibly unknown) state of the repository. Even -D seems a little scary unless you have spent enough time looking in the repository to verify that, at the time specified, the baseline is consistent. I would think that with the situation above, doing a cvs tag VENDOR_R2_MERGED in the working directory where conflict resolution was finished would be the safest method, to be sure you tagged the resolved files and not something else. Thanks for any clue sticks. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
using cvs to contol system files
Has anyone out there used to cvs to version control system files? For instance, files in /etc. I'm working with 2 system admins who want to do this. We were going to make the 'live' files a sandbox that they would share. I was hoping to have them edit files by logging in to their regular accounts, su to root, edit a file, exit su, cvs commit filename. The problem is the permissions involved. They each have a umask of 022 on regular accounts. So a 'cvs add dirName' creates a directory in the repository without group write. No problem, we'll set this one by hand. The CVS/Entries file however is left as owned by the last user to commit and without a group write. This is a problem for the next admin to commit. Is there a way around this. Setting the umask in the admins regular accounts to 002 seems like a poor option. Just getting started on this problem. Any advice is appreciated. -- Protect yourself from spam, use http://sneakemail.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: tag vs rtag question
On Wed, Oct 23, 2002 at 01:49:36PM -0500, Todd Denniston wrote: Nick Patavalis wrote: You merge the local changes cvs co -j VENDOR_R1 -j VENDOR_R2 module You resolve the confilicts, test the new sources, and generaly make sure that everything is stable. Then commit your changes. Several commits may be necesairy since the conflict resolution may take some time. No problem though since the rest of the developers are safely isolated in the VENDOR_R2_MERGE branch). When you have finished with the conflict resolution and tests you tag the trunk accordingly cvs rtag VENDOR_R2_MERGED If at the point the rtag is ran above the last commit of a file happened on the branch would rtag place the tag on the HEAD version of the file (what we want here, I think) or on the branch version of the file? The tag will be placed on the most recent revision of the trunk (i.e the HEAD). ...Though I also have some confused ideas about what exactly HEAD means. Could please a CVS guru give us a precise *definition* of what the HEAD tag is? I would think that with the situation above, doing a cvs tag VENDOR_R2_MERGED in the working directory where conflict resolution was finished would be the safest method, to be sure you tagged the resolved files and not something else. True! /npat -- flowchart, v.: To obfuscate (a problem) with esoteric cartoons. -- Stan Kelly-Bootle ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: tag vs rtag question
I would think that with the situation above, doing a cvs tag VENDOR_R2_MERGED in the working directory where conflict resolution was finished would be the safest method, to be sure you tagged the resolved files and not something else. On the other hand, if you have *deleted* a file, cvs tag won't tag the repository file. This can lead to interesting file reappearing in my workarea problems when others update to the tag.. Tough call. I used to do merges late in the day when concurrent checkins were unlikely. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: tag vs rtag question
On Wed, Oct 23, 2002 at 01:58:27PM -0700, Shankar Unni wrote: I would think that with the situation above, doing a cvs tag VENDOR_R2_MERGED in the working directory where conflict resolution was finished would be the safest method, to be sure you tagged the resolved files and not something else. On the other hand, if you have *deleted* a file, cvs tag won't tag the repository file. This can lead to interesting file reappearing in my workarea problems when others update to the tag.. Can you elaborate a bit on this? You mean deleted by the developers while working in the branch, or while doing conflict resolution in the trunk? /npat -- Dijkstra probably hates me -- Linus Torvalds, in kernel/sched.c ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: tag vs rtag question
Oh, back at my previous employer, we had a branched development tree, and used to merge from the branch into the mainline on a regular basis. After each merge, we would tag the last version merged into mainline on the branch, and use that as the base for the cvs update -j the next time around. The problem was, if one of the files was *deleted* on the branch, cvs tag wouldn't move the tag for that file - you'd have to use cvs rtag for it. The developer in question had done separate cvs rms on the mainline and the branch, but since the deleted version on the branch wasn't tagged, when I did the next merge from the branch to the mainline, the deleted file reappeared. Anyway, the bottom line was to *carefully* use cvs rtag.. -Original Message- From: Nick Patavalis [mailto:npat;inaccessnetworks.com] Sent: Wednesday, October 23, 2002 2:13 PM To: Shankar Unni Cc: 'CVS-II Discussion Mailing List' Subject: Re: tag vs rtag question On Wed, Oct 23, 2002 at 01:58:27PM -0700, Shankar Unni wrote: I would think that with the situation above, doing a cvs tag VENDOR_R2_MERGED in the working directory where conflict resolution was finished would be the safest method, to be sure you tagged the resolved files and not something else. On the other hand, if you have *deleted* a file, cvs tag won't tag the repository file. This can lead to interesting file reappearing in my workarea problems when others update to the tag.. Can you elaborate a bit on this? You mean deleted by the developers while working in the branch, or while doing conflict resolution in the trunk? /npat -- Dijkstra probably hates me -- Linus Torvalds, in kernel/sched.c ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: tag vs rtag question
On Wed, Oct 23, 2002 at 02:24:47PM -0700, Shankar Unni wrote: The problem was, if one of the files was *deleted* on the branch, cvs tag wouldn't move the tag for that file - you'd have to use cvs rtag for it. The developer in question had done separate cvs rms on the mainline and the branch, but since the deleted version on the branch wasn't tagged, when I did the next merge from the branch to the mainline, the deleted file reappeared. Oh, I see. You mean that you were using the *same* tag-name and you were just pushing it forward to more recent revisions, and that this didn't behave well when the push was crossing a delete operation! Tricky, indeed! /npat -- Don't ever think you know what's right for the other person. He might start thinking he knows what's right for you. -- Paul Williams, `Das Energi' ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: using cvs to contol system files
-Original Message- From: [EMAIL PROTECTED] Sent: Wednesday, October 23, 2002 2:22 PM To: [EMAIL PROTECTED] Subject: using cvs to contol system files Has anyone out there used to cvs to version control system files? For instance, files in /etc. We use CVS for controlling our software but for the system files I find that RCS is generally sufficient. RCS is simple to use and gives you version control with few commands to know. If you have not used it, this is what you could do: as root cd /etc mkdir RCS check in the file and leave it in a checked out state with a lock (-l) ci -l filename This will prompt you for a remark that you end with a single line containing a period. This creates a RCS/filename,v file. Then each time you want to change it: as root cd /etc check that no one has changed the file without checking their changes in rcsdiff filename if there are diffs you should check the file in before making more changes ci -l filename then make your changes and check the file in with a lock (-l) ci -l filename if you want to see the history use rlog filename From the rlog information you can see differences between revisions rcsdiff -r rev -r rev filename If you need to fall back on a file use co -p -r rev filename filename Instead of placing all the /etc files into RCS, we ci only the files that we need to change. I also use RCS to control what I have in my /home directory such as my .profile The RCS commands have many options. O-Reilly's book UNIX in a nutshell has a chapter on RCS. Dale Miller Northrop Grumman IT ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: using cvs to contol system files
[ On Wednesday, October 23, 2002 at 17:38:05 (-0500), Miller Dale Contractor HQ AFWA wrote: ] Subject: RE: using cvs to contol system files We use CVS for controlling our software but for the system files I find that RCS is generally sufficient. RCS is simple to use and gives you version control with few commands to know. I concur 100% I have in the past devised procedures and processes to use CVS to manage system configurations (which ended up having to be much more complex than vi1pdqyo02 was proposing), but I would not do so ever again without using something like GNU Cfengine to do the work and then just use CVS to manage the cfengine inputs. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: using cvs to contol system files
On Thu, 2002-10-24 at 05:21, [EMAIL PROTECTED] wrote: Has anyone out there used to cvs to version control system files? For instance, files in /etc. I'm working with 2 system admins who want to do this. We were going to make the 'live' files a sandbox that they would share. I was hoping to have them edit files by logging in to their regular accounts, su to root, edit a file, exit su, cvs commit filename. The problem is the permissions involved. They each have a umask of 022 on regular accounts. So a 'cvs add dirName' creates a directory in the repository without group write. No problem, we'll set this one by hand. The CVS/Entries file however is left as owned by the last user to commit and without a group write. This is a problem for the next admin to commit. Is there a way around this. Setting the umask in the admins regular accounts to 002 seems like a poor option. Just getting started on this problem. Any advice is appreciated. The way I do it is use cvs with make. Use CVS to store secure versions of the files, then every time you want to modify them, create a sandbox, make your changes, then run 'make'. EG, for a set of mail files for a bunch of machines: cvs -d (repository) checkout mail cd mail vi (host).aliases cvs commit make The make script copies the changed aliases file to the proper host and directory, ensures permissions and ownerships are correct and runs newaliases. (It would probably be 'safer' if it did a cvs export of the relevant file instead of copying the sandbox version, but this is just a home network so some imperfections are ok. (G) ) You could also have a script that runs whenever a change is committed, that does the export/check permissions/run stuff like 'newaliases' or restart services. Jenn V. -- Do you ever wonder if there's a whole section of geek culture you miss out on by being a geek? - Dancer. [EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Have CVS perform actions on all files before checking in?
Is it possible to have CVS perform some type of action on types of files before checking it in? I'd like to configure our server for all java and C++ code to do some nicetys, like strip out ^M's and replace bloody tabs with spaces where people put them in. Both actions I can manually do from the command line fairly simply, but it would be great to have CVS just do it for me(and everyone else). For this I would definatly want to be able to specify what files it does it to, as makefiles would get messed up if the tabs were gone. Any ideas? -grant ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Have CVS perform actions on all files before checking in?
--- Schoep, Grant @ STORM [EMAIL PROTECTED] wrote: Is it possible to have CVS perform some type of action on types of files before checking it in? I'd like to configure our server for all java and C++ code to do some nicetys, like strip out ^M's and replace bloody tabs with spaces where people put them in. Both actions I can manually do from the command line fairly simply, but it would be great to have CVS just do it for me(and everyone else). For this I would definatly want to be able to specify what files it does it to, as makefiles would get messed up if the tabs were gone. Although this is possible through the commit info hook, it is highly recommended that it NOT be done since doing so will confuse the client that did the checkin. Specifically, the client knows it has checked in version, say, 1.5 of a file and that it looks a certain way. At the same time, the server (eg repository) knows that version 1.5 of a file has just been checked in and that it looks another way. Mass confusion will occur. So, what to do? Rather than having the commitinfo hook modify the files, just have it reject the checkin until the files fit the coding standard. The only version control tool I know that's able to handle properly file modification upon checkin is ClearCase. HTH, Noel __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
FW: cvs [checkout aborted]
Title: cvs [checkout aborted]
-Original Message-From: Shishir Singhai
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, October 23,
2002 11:34 AMTo: PushpaSubject: RE: cvs [checkout
aborted]
Hi
Pushpa
I dont
know that what you aredoing so I am explaining whole process for using
pserverexcept changes for /etc/inetd.conf and /etc/services which
you changed already.
first
of all edit $CVSROOT/CVSROOT/passwd file to put in entries in that
file. The entries in passwd file goes as
username : passwd(encrypted) : system
Username(optional)
the
Script for generating password is as follows
#!/usr/bin/perl
srand (time());
my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65 : 97))";
my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
my $plaintext = shift;
my $crypttext = crypt ($plaintext, $salt);
print "${crypttext}\n";
say you saved this file as passgen.pl than you can generate password as passgen.pl "Password" XAsesdsOwill give you some encrypted passwd which you copy paste in front of username say xyz than your passwd file shd look likexyz:XAsesdsOyou can use the command:pserver:[EMAIL PROTECTED]:/home/cvsroot/acca_c1b loginand in winCVS what is your settings in Admin-Preferencesregards Shishir Singhai
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of PushpaSent:
Wednesday, October 23, 2002 5:46 AMTo:
[EMAIL PROTECTED]Subject: cvs [checkout
aborted]
Hi All,
cvs server: cannot
find module `acca_c1b' - ignored cvs [checkout aborted]: cannot expand
modules I am
getting this error when I try to check out the module using WinCVS 1.11 module
c1btool Setting in WinCVS is
:pserver:[EMAIL PROTECTED]:/home/cvsroot/acca_c1b
In the server in inetd.conf file
have the following line etc/inetd,conf cvspserver stream tcp nowait root /usr/local/bin/cvs cvs
--allow-root=/home/cvsroot/acca_c1b pserver etc/services cvspserver
2401/tcp cvspserver 2401/udp The environment variable is set to CVSROOT=/home/cvsroot In CVSROOT directory in modules file
c1btool -a acca_c1b
Could someone help
to solve the problem.
Thanks in
advance.
Regards
Pushpa
