CVS fo Japanese OS
i have been using CVS for english NT machine, but we have some Japaneseproject goin on now so most of the machines have be converted to Japanese OS95 for the japanaese OS. I wanted to know whether i can use the CVS1.10.8 version which we r currently using is compatible with japanese OS 95bcos when we i tried to use the same i got an error message saying policy.dll error can anybody help about how to get thro' this problem is thereCVS in for Japanese OS ... or is there any other solution for the sameAjith BEGIN:VCARD VERSION:2.1 N:Shenoy;Ajith FN:Ajith Shenoy EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20001024T065328Z END:VCARD
Modify the export command
Hi! The question: is there a way to exclude certain directories under a module when I make an export on that module? (apart from not tagging that directories, since we want to tag the whole module and all its subdirectories). Can you modify the export command? Background: We will build our developing environment approximately like this: Main_module |__scripts |__docs |__db_files The production environment will have this structure: Main_module |__scripts |__db_files Now, when I make an export to a temporary release directory which I will then tar and send over to the production environment I also get the docs directory, since we tag the whole Main_module. Can you automate the export to exclude certain things? Thanks in advance! /Patrik ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
subscribe info-cvs
-- -- Pierre-Antoine Briandet chez.com [EMAIL PROTECTED] -- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout aborted: end of file from server
Ben Keating wrote: For me, however, when I type the following, this is what happens: cvs -td :ext:accnt on Repos@Repos:/location of repos co name of module - Starting server: rsh Repos -l usr name /location of cvs binary server cvs [checkout aborted]: end of file from server (consult above messages if any) "end of file from server" means CVS read EOF from RSH which could mean that it never connected at all. Read the "Trouble making a connection to a CVS server" section of the manual: http://cvshome.org/docs/manual/cvs_21.html#SEC182 Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- This sentance has threee errors. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login error with pserver on Windows 98
Dennis Jones wrote: Thanks. The NT client didn't have a HOME variable set, and yet it worked. So, I don't understand why, but setting the HOME environment variable in Windows 98 did the trick. Thanks again. - Dennis I believe NT automatically sets HOMEDRIVE and HOMEDIR or something similar, which CVS knows it can squish together to compose HOME. 98 doesn't set those so CVS needs HOME set. Incidentally, if you set HOME on NT, I think CVS would use it instead, but there's no need. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not call my teacher "Hot Cakes". I will not call my teacher "Hot Cakes". I will not call my teacher "Hot Cakes"... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: problem with diff -N
* $ from [EMAIL PROTECTED] at "23-Oct: 7:40pm" | sed "1,$s/^/* /"
*
*
* -BEGIN PGP SIGNED MESSAGE-
* Hash: SHA1
*
* As the nightly build manager for AbiWord, I recieved a request for diff's
* between the latest released source and the current cvs source. CVS makes
* this easy to generate, so I added it. Then it turned out that this didn't
* include the newly added files, so I added the -N command (which I have
* always used for GNU diff).
*
* That's when it didn't work. I turns out that the -N command does generate
* diffs for the new files, but it doesn't do them in the nice way that GNU
* diff does. Instead, it labels the old file as /dev/null and the new file
* as a randomly named denizen of /tmp. Needless to say, this doesn't make
* patch too happy (even it isn't that smart).
*
* My question is, is there any way around this? Can I generate the diffs
* that I have been asked for, with reasonable file names? This works just
* fine diffing the checked-out copy and a new copy, with GNU diff. Is there
* any way to accomplish this with CVS diff?
I posted the same question (but worded differently) last week and got no
response.
Here is my solution (a target in a makefile)
pre-audit-diff:
cvs -q rdiff -u -kk -r PRE_AUDIT trux/$(RDIR)/$(TARSRC) | sed -e
's@trux/$(RDIR)/@@'
trux is the name of the repo,
RDIR is the current directory in the repo
TARSRC is the directory containing the piece of code I'm maintaining
For some reason rdiff works, diff doesn't (rdiff doesn't take the -N, but still
does the right thing).
*
* Thanks
*
*
* sam th
* [EMAIL PROTECTED]
richard.
---
Richard Offer Widget FAQ -- http://reality.sgi.com/widgetFAQ/
{X,Motif,Trust} on {Irix,Linux}
__http://reality.sgi.com/offer/
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
cannot rename file...
I'm having this problem described in the troubleshooting section: cvs [checkout aborted]: cannot rename file file to CVS/,,file: Invalid argument This message has been reported as intermittently happening with CVS 1.9 on Solaris 2.5. The cause is unknown; if you know more about what causes it, let us know as described in section Dealing with bugs in CVS or this manual. Problem is, it's not on Solaris. It's on WinCVS writing to a network drive. I created the repository and have no problems. I use cvs on linux that writes to the nfs mounted drive. The person I'm working with is using WinCVS and continuously get that error. I think the drives are network appliances that allow NFS and SMB connections. I didn't have this problem when I was using a pserver. That is, WinCVS and UNIX CVS worked together flawlessly. Thanks for any insight into this problem. -- Jiann-Ming Su, [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS 1.11 export with BINARY files (problem)
Hello, I've checked out the archives and seem to be having a problem that was supposedly fixed back in the 1.9 version of CVS. However, I'm running a freshly compiled 1.11 on Sun Solaris and experience the same problem as described earlier. I am using CVS as a version system for a web enabled application. All images are stored in a single directory and have been added to the repository using the -kb option. When I check out the files, everything is great. If I use the export command, though, the binary files come through in a corrupt format. I've verified that the files are correctly entered as binary, as shown in this output from cvs status: File: Welcome.gif Status: Up-to-date Working revision:1.5 Repository revision: 1.5 /opt/cvs/dev/hydra/images/Welcome.gif,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: -kb Existing Tags: start (revision: 1.1.1.1) CURRENT (branch: 1.1.1) Has anyone else seen this issue appear in recent versions of CVS and if not, is there more information that I should supply in order to help weed out this 'feature'? Thanks, Scott Milliken ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login error with pserver on Windows 98
They must be implicitly defined, because there are no environment variables with those names that I can find. - Dennis - Original Message - From: "Derek R. Price" [EMAIL PROTECTED] To: "Dennis Jones" [EMAIL PROTECTED] Cc: "David L. Martin" [EMAIL PROTECTED]; "CVS Mailing List" [EMAIL PROTECTED] Sent: Tuesday, October 24, 2000 7:19 AM Subject: Re: login error with pserver on Windows 98 Dennis Jones wrote: Thanks. The NT client didn't have a HOME variable set, and yet it worked. So, I don't understand why, but setting the HOME environment variable in Windows 98 did the trick. Thanks again. - Dennis I believe NT automatically sets HOMEDRIVE and HOMEDIR or something similar, which CVS knows it can squish together to compose HOME. 98 doesn't set those so CVS needs HOME set. Incidentally, if you set HOME on NT, I think CVS would use it instead, but there's no need. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not call my teacher "Hot Cakes". I will not call my teacher "Hot Cakes". I will not call my teacher "Hot Cakes"... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Commitinfo question
I agree with Dennis' comments, but I would add a few things. First, I believe and recommend that there should be a differentiation between "checked-in code" and "code that is eligible for the build." There are several reasons for this: Developers should be encouraged to commit their code early and often; a hand-off process process quantifies the changes made between builds, making them easier to report; a hand-off process also enables sharing of early code without having it prematurely affect builds used by other parties, such as Q/A; adopting a task-oriented approach allows for the addition and removal of specific features (within limits) in special circumstances. Developers should be encouraged to commit code early and often. This is somewhat obvious, because by making copies of the code under development spreads risk in case of a system failure. It's becoming more common for IT departments to forego backing up individual workstations, favoring large fileserver arrays instead. Some people copy their work areas to a backed-up stoarage area, but I believe that committing at the end of the day is better practice if for no other reason than someone else can perform a checkout and resume development if a colleague is hit by a bus. It's also important to note that if work is distributed in such a way that the directory trees that individual developers modify are somewhat isolated, then branching is unnecessary if workgroups choose specific timestamps or tags of known working code to update their sandboxes with. Alternatively, known good baseline builds can be replicated in a user's sandbox and modified. A hand-off process quantifies changes made between builds, making them easier to report. During the hand-off process, an inventory of the affected files is taken, which in the end is a partial (or complete) difference between two builds. This difference typically takes the form of a set of files, each file associated with a range of version numbers. Tools such as rinfo can be brought to bear with this information to produce meaningful change reports upon completion of a build. In addition, a tight integration between the hand-off process and the defect tracking system can modify the status of the defect to indicate that the developer is done. A really good integration can also record the exact files and version numbers implementing the repairs and change the status of the defect, perhaps to indicate that the developer is done but the fix is not yet available for testing. (Subsequent updates at the completion of the build specify a state where features are available for testing.) A hand-off process also enables sharing of early code without having it prematurely affect builds used by other parties, such as Q/A. Though CVS provides branching capabilities to isolate work, developers frequently view them as overhead and some have difficulty understanding them. If developers adopt a standard for code-sharing (which may be less rigorous than the acceptance criteria for Q/A) then they may commit code meeting that standard and permit colleagues to update their working areas with the new code. This formalizes the tried-and-true method of copying files out of other users' environments, which is often used to circumvent formal, heavyweight processes. There is also has the bonus effect of avoiding merge conflicts of identical changes between the sharing parties later. The code becomes real during the hand-off, which enforces the higher quality standard. Adopting a task-oriented approach allows for the addition and removal of specific features (within limits) in special circumstances. By collecting sets of files, each with a range of version numbers, there are now handles for specific features implemented by each set. By treating such sets of files as units, specific features can be included or excluded from builds. The decision for inclusion can be made via automation or review. A form of automation would be an assumption for inclusion into a build, which subsequent removal after an analysis of a build failure. A review could be a defect triage in which a committee makes the decision to include or exclude a specific feature in the product. The sum of these features provide a very nice environment in which build reports provide not only success/fail states and compilation error messages, but also difference reports identifying specific changes to files and the developers' commentary. Defect databases are automatically updated to indicate specific files and their versions that implement repairs, and queries show whether or not specific features are available for testing. (Or in the event of a build failure, defects can be returned to the developer.) But most importantly, the build success rate can be increased (to as high as 100% success, depending on such factors as resource availability, build duration and the sophistication of the backout mechanism) while allowing the development teams to
RE: CVS 1.11 export with BINARY files (problem)
Larry, I have attempted to export both with and without the -kb option to the export command. I am not using a ~/.cvsrc configuration file, either. I have also used an alternate client - namely WinCVS 1.1 beta 16 and the version of CVS that comes with that package. It, too, will checkout correctly but corrupt on export, leading me to believe that the server side is the problem. Any other ideas? Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 24, 2000 1:32 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: CVS 1.11 export with BINARY files (problem) Milliken, Scott writes: All images are stored in a single directory and have been added to the repository using the -kb option. When I check out the files, everything is great. If I use the export command, though, the binary files come through in a corrupt format. Since Solaris, like other Unix systems, does not distinguish between text and binary files, the problem must be keyword expansion. Are you specifying a -k option to the export command (perhaps in your ~/.cvsrc file)? If so, that will override the -kb from the repository and quite likely screw up your binaries. -Larry Jones Start tying the sheets together. We'll go out the window. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 export with BINARY files (problem)
Milliken, Scott writes: All images are stored in a single directory and have been added to the repository using the -kb option. When I check out the files, everything is great. If I use the export command, though, the binary files come through in a corrupt format. Since Solaris, like other Unix systems, does not distinguish between text and binary files, the problem must be keyword expansion. Are you specifying a -k option to the export command (perhaps in your ~/.cvsrc file)? If so, that will override the -kb from the repository and quite likely screw up your binaries. -Larry Jones Start tying the sheets together. We'll go out the window. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Modify the export command
=?iso-8859-1?Q?Patrik_Sj=F6berg?= writes: The question: is there a way to exclude certain directories under a module when I make an export on that module? (apart from not tagging that directories, since we want to tag the whole module and all its subdirectories). Can you modify the export command? Not directly, but you can make a new module that's an alias for the existing module but excludes certain directories -- see: http://www.cvshome.org/docs/manual/cvs_18.html#SEC159 -Larry Jones I wonder if you can refuse to inherit the world. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cannot rename file...
Jiann-Ming Su writes: Problem is, it's not on Solaris. It's on WinCVS writing to a network drive. Don't put repositories on network drives -- use some form of client/ server CVS instead. Your problem is almost certainly some kind of conflict between DOS and Unix file sharing semantics. -Larry Jones All this was funny until she did the same thing to me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Derek R. Price writes: I'm thinking maybe the standard test comes close to the argument length limit and something about your system pushes it over the edge. On many systems, the environment counts against the maximum argument length limit; if you've got a lot of enviroment variables or some with very long definitions, try deleting them before running the tests. (You may find env -i [some versions use - instead of -i] to be a handy way to do that.) -Larry Jones Why is it you always rip your pants on the day everyone has to demonstrate a math problem at the chalkboard? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 export with BINARY files (problem)
Milliken, Scott writes: I have attempted to export both with and without the -kb option to the export command. I am not using a ~/.cvsrc configuration file, either. I have also used an alternate client - namely WinCVS 1.1 beta 16 and the version of CVS that comes with that package. It, too, will checkout correctly but corrupt on export, leading me to believe that the server side is the problem. Any other ideas? You say you used an "alternate" client -- does that mean that the original problem was also client/server CVS? If so, that's a critical piece of information you neglected to provide -- what platform and CVS version are you using for the client and server? (You said Solaris and CVS 1.11, but it's not clear whether that's the client, the server, or both.) What form of client/server are you using (:ext:, :pserver:, etc.)? Does the problem still occur if you run CVS on the server machine with a local repository? -Larry Jones What a waste to be going to school on a morning like this. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: diff in commit message (was: Multiple-line log message)
On Mon, Oct 23, 2000 at 14:59 -0500, Giang, Richard P wrote: Does anyone know how to enter a log message that expands multiple lines using command line cvs commit -m? Does anyone know a method how to incorporate "cvs diff" into the "cvs commit" message and thus aid the committer with showing what has changed when he is asked to specify what he did and why? As a background: At the moment I employ a homegrown wrapper script around RCS to catch the diff before invoking an editor with the diff log and the "tell me why you did it" message. I tried to accomplish something similar in CVS, but failed miserably. :( The rcsinfo is too static (updated only with "cvs update", not referenced when -m is specified). Setting an CVSEDITOR pointing to a script to invoke "cvs diff" and "$EDITOR" hangs due to the lock already set by "cvs commit". So I realized I had to fiddle with the source and narrowed it down to commit.c at a time where start_server() is done but do_editor() is not yet. That's where I would catch the diff output and append it to the saved_message. Where am I wrong? What did I miss? Has someone already done this successfully? virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: diff in commit message (was: Multiple-line log message)
On Tue, Oct 24, 2000 at 08:54:37PM +0200, Gerhard Sittig wrote: Does anyone know a method how to incorporate "cvs diff" into the "cvs commit" message and thus aid the committer with showing what has changed when he is asked to specify what he did and why? I would have to say, this is probably the ugliest idea I have ever seen. You really want to do this on a regular basis? Why? this information can ALWAYS be regenerated outside of the log message. As a background: At the moment I employ a homegrown wrapper script around RCS to catch the diff before invoking an editor with the diff log and the "tell me why you did it" message. Why not a mycommit.sh that looks like the following: CVSEDITLOG=/tmp/log.$$ cvs up $CVSEDITLOG CVSEDITOR=mycommitedit.sh export CVSEDITLOG CVSEDITOR cvs commit rm /tmp/log And mycommitedit.sh that looks like: cat $CVSEDITLOG $1 vi $1 That is, instead of trying to shoe horn into cvs commit, put a wrapper around it. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 export with BINARY files (problem)
Milliken, Scott writes: PREVIOUS: cvs export -f -D 20001024 hydra NEW: cvs export -f -D today hydra I would have thought that specifying today's date would have given me the latest from today, but that's not the case. No, it's not. "20001024" is interpreted as "20001024 00:00:00" whereas "today" is a synonym for "now". -Larry Jones Santa's gonna skip this block for years. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Visually Viewing Branches and Tags
On Wednesday, October 25, 2000 9:05 AM, Matthew Hahn [SMTP:[EMAIL PROTECTED]] wrote: Hello, Does anyone know of a tool or program that parses through an RCS file or even through a CVS repository and outputs a graphical (ASCII graphics is plenty graphic) tree-like structure of CVS branches and tags. Thanks. WinCVS and tkCVS both give this functionality on a per file basis, but only for checked out files. I'm not sure about jCVS as its a while since I looked at it. *** Chris CameronOpen Telecommunications NZ Ltd Senior Solution Architect [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Visually Viewing Locks in WinCVS and WinCVS help documentation
Does anyone know how to visually view locks in WinCVS so that when you checkout a module, any locked files are displayed differently (eg in a different colour, similar to when you modify a file)? Also where can I get help documentation on the WinCVS gui? Thanks, Vince +61 2 9005 5939 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Commitinfo question
Thanks to both of you for the very informative (and long) replies. Perhaps I should clarify my intentions in setting up the system that I described. My team is building a system that enforces the policy that a developer should only commit code that has been code reviewed, and is ready to be included in the build. This way the repository contains only "blessed" code, and whoever does a cvs update picks up clean code that is guaranteed to have been built and tested. Paul, I like your ideas about differentiating "checked-in code" from "code that is eligible for the build," and I will discuss these ideas with my team. Unfortunately, I am currently not in a position to decide on policy issues such as this (being a humble intern), and I am still trying to solve my original problem. Have either of you (or anyone else on this list) built any kind of custom system onto CVS, using the commitinfo file to validate commits? If so, I would appreciate any tips on making such a system succeed, or information on the problems that occur with this type of setup. Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 24, 2000 10:57 AM To: [EMAIL PROTECTED] Subject: Re: Commitinfo question I agree with Dennis' comments, but I would add a few things. First, I believe and recommend that there should be a differentiation between "checked-in code" and "code that is eligible for the build." There are several reasons for this: Developers should be encouraged to commit their code early and often; a hand-off process process quantifies the changes made between builds, making them easier to report; a hand-off process also enables sharing of early code without having it prematurely affect builds used by other parties, such as Q/A; adopting a task-oriented approach allows for the addition and removal of specific features (within limits) in special circumstances. Developers should be encouraged to commit code early and often. This is somewhat obvious, because by making copies of the code under development spreads risk in case of a system failure. It's becoming more common for IT departments to forego backing up individual workstations, favoring large fileserver arrays instead. Some people copy their work areas to a backed-up stoarage area, but I believe that committing at the end of the day is better practice if for no other reason than someone else can perform a checkout and resume development if a colleague is hit by a bus. It's also important to note that if work is distributed in such a way that the directory trees that individual developers modify are somewhat isolated, then branching is unnecessary if workgroups choose specific timestamps or tags of known working code to update their sandboxes with. Alternatively, known good baseline builds can be replicated in a user's sandbox and modified. A hand-off process quantifies changes made between builds, making them easier to report. During the hand-off process, an inventory of the affected files is taken, which in the end is a partial (or complete) difference between two builds. This difference typically takes the form of a set of files, each file associated with a range of version numbers. Tools such as rinfo can be brought to bear with this information to produce meaningful change reports upon completion of a build. In addition, a tight integration between the hand-off process and the defect tracking system can modify the status of the defect to indicate that the developer is done. A really good integration can also record the exact files and version numbers implementing the repairs and change the status of the defect, perhaps to indicate that the developer is done but the fix is not yet available for testing. (Subsequent updates at the completion of the build specify a state where features are available for testing.) A hand-off process also enables sharing of early code without having it prematurely affect builds used by other parties, such as Q/A. Though CVS provides branching capabilities to isolate work, developers frequently view them as overhead and some have difficulty understanding them. If developers adopt a standard for code-sharing (which may be less rigorous than the acceptance criteria for Q/A) then they may commit code meeting that standard and permit colleagues to update their working areas with the new code. This formalizes the tried-and-true method of copying files out of other users' environments, which is often used to circumvent formal, heavyweight processes. There is also has the bonus effect of avoiding merge conflicts of identical changes between the sharing parties later. The code becomes real during the hand-off, which enforces the higher quality standard. Adopting a task-oriented approach allows for the addition and removal of specific features (within limits) in special circumstances. By collecting sets of files, each with a range of version numbers, there are now
[ANNOUNCE] cvsauth 0.2.1
Hi, the new developement version supports full ssl encryption even with the data! Now you have 3 connection methods: Method PORT AUTHORISATION DATA :sserver 2401 sslplain text :s2server 2405 sslplain text :sslserver 2405 sslssl We should find a way how to add easily new access methods to the cvsclient, currently every access method needs to be edited in 7 (?) locations. Martin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Any body Integrated CVS with VC++ IDE
Hello folks, Any body Integrated CVS with VC++? I follwed all the steps according to MSCC standards but still in my IDE Source Controll menu is not appearing... What could be the reason?? Thanks.. Raghu K Software Engineer Pretzel Logic Sofware Inc. Cupertino, California email : [EMAIL PROTECTED] phone: 408-366-9010 extn 338 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
