Re: CVS on OS X, Tortoise client on PC
mattmattmatt wrote: I have CVSNT for mac installed [www.cvsnt.org] on the mac, and the CVS client is accessible from the command line for our development user account (just one account for now is fine). I can create new modules in the repository locally and check files in and out without problems. SSH runs fine, the account can log in remotely without issue. Wow.. someone got it to work out of the box :) The OSX version isn't particularly good at the moment... It *works* but the installer is a bit naff. I've got a Mac Mini on order so I can get the installation working properly (the next version* will have rendezvous support** as well, plus resource fork support that was merged in a little while back). Tony * Couple of weeks, probably ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Latest core CVS source
I checked out the core CVS development tree and it doesn't compile at the moment... also it didn't have any of the latest patches in... Is there a ready-patched version with all the up to date fixes/patches in it (like the 'edit -c' stuff and various other things like the 'ls' patch I've heard mentioned). (btw. I'm not subscribed to info-cvs any more, please reply by email or via [EMAIL PROTECTED]) Tony -- Where a calculator on the ENIAC is equpped with 18,000 vaccuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weigh 1 1\2 tons. -- Popular Mechanics, March 1949 [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Latest core CVS source
Larry Jones wrote: By "core CVS development tree", do you mean what's in CVS at :pserver:[EMAIL PROTECTED]:/home2/cvsroot? If so, that code is built every night on a bunch of different platforms and the sanity tests run. It works just fine -- what problems did you have compiling it? The makefiles are corrupt (at least on the Linux box I tried it on). It doesn't even start compiling. There's also a missing variable (client_active) referenced in 4 or 5 places in the code. As for "latest patches", there are boat-loads of patches running around loose, most of them ill-conceived and poorly implemented; naturally, they've not been incorporated into the official release. (Of course, there are a few gems that haven't been incorporated, either; separating the wheat from the chaff is a difficult and time-consuming process and we don't have a paid development staff, you know.) 'edit -c' has been around for almost 2 years... The core code looks pretty stagnant if it's that far behind. You don't need paid development staff - I've worked on many projects that didn't have such staff. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Cvsnt] Re: Latest core CVS source
Terris wrote: This is a good example of why Microsoft has nothing to fear from open source. I wouldn't use cvs as an example... it's in the same state gcc was in before it forked and became egcs (which has since become the official release again). If you look at stuff like the linux kernel, or XFree86, their development moves quite quickly. Stuff is tried, either works or doesn't work, then moves on. Even cvsnt moves quicker. If someone sends me a patch I look at it - 90% of them are 'obviously correct', a few need some clarification. I'll then put the patch in with a 'try this it's new and might not work properly' warning... if nobody complains it stays in. I've only really broken the tree once that I can remember, and that version never got released. cvsnt would be much worse off if I hadn't applied, for example, the diff patches (which reduced the number of false conflicts to almost zero). Of course, to be fair, something like this would never happen with the Perl tree. A good example... The new perl 6 stuff looks interesting. Tony -- Don't click on this sig - a cyberwoozle will eat your underwear. [EMAIL PROTECTED]http://www.nothing-on.tv ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Virus Warning
Brian Huddleston wrote: That this type of virus propogates at all seems fairly conclusive evidence that some people aren't as bright as your average sedimentary rock. I'm sure we're eventually going to get a warning about "New Destructive FORMAT.EXE virus Discovered in the Wild!" Someone recently send around the 'Honor Virus' (delete all your files and pass it on, you've probably seen it). A director of the company, who shall remain nameless, actually emailed me worried about this new 'virus' and whether any of our systems were infected. I had to keep a straight face when I told him it was a joke email. It wasn't easy... Tony -- "User DATA\tmh cannot be created because DATA\tmh does not exist." Windows -- Great UI huh? [EMAIL PROTECTED]http://www.nothing-on.tv ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: My first stumper ...
Matt Gregory wrote: I've been managing our CVS use for about 3 years now and up until today I've been able to figure out an explanation for every weird CVS behavior. Here's what's happening: Developer A updates file x and gets version 1.200. However, changes are missing that exist in version 1.196. Developer B also updates file x and gets version 1.200, but has the changes from 1.196. Developer B is confused, so B adds a comment to file x and commits it Hmm another one... I've been seeing dropping of updates for a while, but it happens rarely I attributed it to errors in the diff algorythm. It seems that sometimes 'cvs update' doesn't change the on-disk file, but *does* change the CVS directory, which causes a revision to be effectively erased on the next commit. It might be that there's a problem when the clocks of the machines aren't in sync (most of the time this has happened it has involved a laptop which doesn't automatically keep in sync like the desktops do). I have watched it happen in front of me with a desktop, though. I committed a bugfix, went to the other machine to update, it said it had done the update, but the bugfix did not propogate. I had to manually delete the file and re-update to cause the new revision to appear. Tony -- The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground in a secret location... and i'm not even too sure about that one"--Dennis Huges, FBI. [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: edit -c companion patch?
Noel L Yap wrote: All these patches (and more!) are availabe at SourceForge under the project RCVS. RCVS looks dead (the last checkin was 7 months ago according to the web view). What is the URL for the up to date version? Tony -- "If a system is of sufficient complexity, it will be built before it is designed, implemented before it is tested and outdated before it is debugged." - McAuley's Axiom [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: [Cvsnt] cvs + M$ Integration with VS IDE]
Laine Stump wrote: The way you previously explained it, he was calling a GPL'ed DLL - that's the same (in the eyes of the GPL) as executing a separate binary. He's not violating the GPL unless his program links in GPL'ed code *at compile time*; runtime is okay. (Of course he should check this out with a lawyer to be sure, but that's the way I've always understood it.) No... DLLs are linked at compile time, just like unix .so files. They are merely loaded dynamically. From the GPL: This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. Also: If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all Tony ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: [Cvsnt] cvs + M$ Integration with VS IDE]
(CC'd to the FSF for some more informed comment) Laine Stump wrote: The only real question is whether or not loadtime/runtime linking is considered "linking" for purposes of the GPL. Since it is acceptable, for example, to have a proprietary LKM that gets "linked" into the Linux kernel at boottime/runtime, I'd say that it looks like it *is* acceptable, but again, I'm not an authority on the intracacies of the GPL. The linux kernel does not *depend* on any proprietary modules, and doesn't ship with any. In fact linking with binary-only modules is explicitly unsupported. This is of course the opposite situation, and there is a very lively debate as to whether this is acceptable (until QT was relicensed under the GPL where were some that said the whole of KDE was in violation of the GPL). Personally I think where you link with a closed library to create a GPL program you are probably OK (even if it is a technical violation). This is not the case here. In this case a GPL program (CVS) has been linked with a closed-source program covered by a microsoft NDA. If you are calling a GPL'ed DLL, you are not incorporating that DLL into your program, you are merely calling it; almost exactly the same as if you were calling cvs.exe with system(). If this weren't acceptable, NetBSD, FreeBSD, and OpenBSD would all be in violation of the GPL, because they load and execute GPL'ed binaries. I'd venture to guess that the legality of those 3 OSes has been closely scrutinized, so again this looks like no problem. The GPL explicitly allows linking with licenses freer than itself (BSD) so the BSD case is covered (and AFAIK BSD doesn't *link* with any GPL software. All the important libraries are LGPL). If the situation were as you describe, there would be nothing to stop Microsoft from including GPL software inside their OS (which is made up of many interconnected DLLs). Personally I use the GPL on my software to prevent such misuse, and would be very upset if it occurred The GPL covers 'derived works'. The software in question is a derived work of CVS, and therefore *must* conform to the GPL or else not be distributed. There isn't an argument about this. You *can* get around it by executing the cvs binary externally and using pipes to talk to it, and I don't know why it wasn't done that way (I've long thought the same about WinCVS, actually). This appears to be OK (otherwise you couldn't use the NT command line to execute a GPL program). Tony ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Cvsnt merge with main cvs source tree ??
"Andrew G. Tereschenko" wrote: Don't you want save your time and give full WIn32 server to core cvs team ?? The diff from cvs-1.10.8 is available from the website. If they want to merge it they can. However I doubt there's any will or intention to do it. There are a lot of binary/text fixes in the cvsnt source tree, several places where I've had to weaken the case sensitivity, etc. to merge that into the main tree would be a lot of work for someone. You'd have to make sure that the existing functionality was unimpaired. I doubt you could do that in all cases. The removal of 'cvs admin -l' was a decision I took after the info-cvs people had just spent a week arguing whether it was a good idea. Ditto the extra error message when the CVSROOT is incorrect. Things like :ntserver: mode are cvsnt specific... those bits won't even compile on a unix system, and I'm not certain it's suficiently protected by #ifdefs. Anyway do the Unix people really want cvs littered with '#ifdef _WIN32'...'#endif' macros? I wish fully functional CVS server for Win32 will be available from main source tree and don't have delays with security/bug fixes issues. Often fixes have been going into cvsnt *before* the main cvs tree. In some ways (cvs edit -c for example) the cvsnt tree is ahead of the main tree (which has been around for a year but still isn't in 1.11). Ultimately it's all GPL software. I don't control it, nor would I wish to. If you want to make patches to add server functionality to the main CVS tree then that's fine by me. It'll make my own diffs smaller. Tony ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
"Greg A. Woods" wrote: If so then I'm afraid there's probably little help you can get beyond that you've already seen. I really can't imagine how it could be made much more lucid, accurate, or usable either! It all looks painfully obvious and extremely well detailed to me. The first guide above does things in the correct order so that you can't go wrong unless you bypass a step before you succeed in completing it. It even covers the few things that seemed to cause confusion with the developers I helped out about a year ago It doesn't mention how to stop SSH asking for a password every time you use it The shsetup program itself is broken (at least on Win2k) but after a bit of ferreting I managed to get something to work. However it's unusable as it is. Tony
If pserver might be going then....
I'd like to switch to using ssh at least for some stuff.. It'd be nice if I could simplify the nt cvs by using it. However I have the following requirements, that don't seem to be met yet (it's probably buried in the ssh docs somewhere?) 1. It is an absolute requirement that the ssh users don't have equate to real users on the server. How do you make an sshd that uses a different passwd file to the system one? (This is an NT thing... Once a user has a userID he can log in. There is no practical way to stop him - removing 'interactive' priveledges only makes it a bit harder). 2. How do you stop cvs-ssh asking for a password for every command that you issue? It's really annoying. Can someone implement 'cvs login' for ssh so it stores the password and feeds it to the ssh process? (Again, an NT thing - rsa authentication is impossible for reasons I outlined in another post). I could probably get issue 2 by hacking the sshd source so it stored a local list of usernames and a list of 'plain text' passwords for remote logins. However with something like this if the server is compromised so are all your users' passwords (also, keeping them in sync is a nightmare). Tony
Re: [HELP] end of file from server problem when client in other domain.
David Penn wrote: if I use localuser in domain2, set preference as :pserver:userin2@cvsserver:cvsrepository, everything is smooth. what happened? any solution? thanks in advance! You can't checkout across domains at the moment, it's broken. I haven't got the means to test it at the moment, so it may well not be fixed for a while. Tony
Re: WinCVS and the info-cvs mailing list
"Cameron, Steve" wrote: Win32 M$ wrote: Dear Laine Stump, Oddly, http://www.wincvs.org points people at this mailing list (the CVS mailing list) when they have questions about WinCVS. I'm not sure why they haven't setup their own mailing list, as other frontends, such as tkCVS, have. It would seem to make *a lot* of sense to do so... [...] Users find it very difficult to distinguish problems with WinCVS and the CVS server. About 50% of the messages to the cvsnt mailing list are WinCVS/tkcvs/jcvs related, another 45% cvs 'core' related (usually because someone hasn't RTFM'd), and the remaining 5% are genuine cvsnt things. I actually don't mind this (because it's a mailing list if I don't answer someone else will usually do it for me) and it's far better than they email me directly (down to two or three a week which often end up in /dev/null). You have to decide whether you really want to support *all* cvs products, because the messages you get won't always be WinCVS specific... If you're very busy, you might be better off allowing people to keep posting to info-cvs. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: Setup NT CVS server with Unix CVS client
"Karthikeyan.K.V" wrote: Hi, The Problem is there are only 2 or 3 Linux CvS clients while the rest of it are Winnt and the winnt server is backed up,raid 5 etc.That's why the problem is all about.And Samba is creating a lot of permission problems for me when the Unix clients try to commit their work in the NT server.Got Stuck up,don't know if this config(NT CVS server and NT and UNIX CVS clients) has been ever worked out.Any inputs are welcomed. Sharing CVS over samba is probably a waste of time... the locking issues alone!!! Use pserver for this. You would be much better putting the CVS server on a linux machine. Remember the NT CVS server is only really a hack for those who have no choice (like me). There are lots of little 'problems' which haven't been resolved yet. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: Using WinCVS with CVS on NT Server
[EMAIL PROTECTED] wrote: Error: Unable to load the library cvs2ntslib.dll You're probably trying to load it on Windows 98. As stated in the readme.nt, this DLL is for NT clients only. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: Setup NT CVS server with Unix CVS client
"Karthikeyan.K.V" wrote: Hi , Thanks, I setup up JCVS in pserver mode from linux to access the CVS NT server.It seems like it is working from what i see in the basic operations.Is there anywhere the list of those little problems we have to face, having setup a CVS NT server, so that iam better prepared for it.Thanks a lot for your help It depends a lot on the local setup. Some people have been unable to get ntserver authentication to work at all (there's probably a registry setting controlling permissions, but it's undocumented AFAIK). WinCVS seems to leave the client connected, so the server doesn't cleanup until you exit it (answer: don't leave WinCVS loaded unless you need it right now). Again, I can't repeat this... The occasional person has trouble with binary files, but that may be due to user error. Limiting user access via Permissions doesn't work (the server runs as LocalSystem). This is a limitation of the NT security model and is unfixable (no setuid support - you need the user password even to drop priviledges!). ntserver mode attempts a fix by using ImpersonateNamedPipeClient, but this in turn breaks access over network shares... pserver is the most reliable at the moment since it's well tested in its Unix incarnation and works well. Also, it's more likely that people will be able to help if you ask a question here... It's not too bad - all the repeatable errors are AFAIK fixed. However local configuration differences can dredge up obscure bugs. I still don't generally recommend using the NT server unless you're prepared for the occasional problem - it's not 'plug and play' by and stretch of the imagination. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
cvs edit -c patch?
Is there somewhere I can download the cvs edit -c patch? I haven't been able to find a copy anywhere... Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: Format of RCS file -- On windows should newline be \n or \r\n
"Tolkin, Steve" wrote: I think that CVS is still using the same file format used by RCS, even though it no longer uses the RCS executables to do its work. True I also think that the RCS file should always follow the Unix convention for a newline, i.e. use the single character \n, even on DOS and Windows systems. I don't think it's documented anywhere. cvsnt has patches which make this true. 'raw' cvs has slight incompatibilities, so you can't share repositories between NT and Unix with it. In contrast the work file should always use the "native" newline convention, i.e. \r\n on DOS and Windows. If by work file you mean checked out files on the client, then yes. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: cvs-nserver 1.10.7.1: new direction for CVS-over-network development
Alexey Mahotkin wrote: It almost cleanly applies to cvs-1.10.8 and, as the matter of fact, the new release of cvs-nserver will be against 1.10.8. The most significant modification of original code is the removal of about 600 lines from server.c, yet it is still way, way too long. Ahh... server.c is the most heavily modified part of cvsnt (Essentially I had to rewrite half of it to use threads rather than forking). Much fun ahead, methinks... There is an obvious task to improve server.c by splitting kerberos- and GSSAPI-related code from it thus creating cvs-kserver and cvs-gserver. There is probably also need to create cvs-sslserver (I have not investigated yet whether we could get along with ssl-tunnel'ed server (we surely can not get along with ssl-tunneled client as it almost has nothing to tunnel)). For NT you would also need cvs-ntserver. It might be worth investigating whether cvs-kserver could be ported to NT too (although the MS documentation on this is worse than useless). It seems to me that checkpassword scheme is sub-perfect for NT though I could be wrong. I've tried to research security aspects of NT but has not reached considerable results. And after I learned about your project and changed job recently hoping not to see MS in a lifetime no more (though it seems like I will have to anyway) I completely relaxed and thought that I'd be better off with CVS under UNIX. Though I will be glad if nserver will influence the development of NT-CVS or vice versa. Under NT you can't do setuid, and you can't check against a pre-encrypted system password. The only way to validate a password is to attempt a non-interactive login (after which you can change you UID to it). Of course this means you need the original plain-text password to work, and this has security implications. There isn't a way around this as far as I can see. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: cvs-nserver 1.10.7.1: new direction for CVS-over-network development
Alexey Mahotkin wrote: I have finally managed to announce that http://alexm.here.ru/cvs-nserver/ contains cvs-nserver-1.10.7.1 for couple of weeks already. cvs-nserver is the rewritten and improved :pserver: mode for CVS. Hmm... How much of a diff is this from the cvs-1.80.8.tar.gz? It'd be nice to be able to add this to the NT version. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: Laptop CVS setup
Sathish Vasudevaiah wrote: I want to setup the following CVS environment and I am hoping that some of you will point out the problems with such a setup or some better ideas. - I have a desktop (Win95) on which I would like to install a CVS server. *Finally* this is where all the version control should happen. Win95 cannot act as a CVS server. If you really want this install NT (or Linux). However you can use shared directories to (mostly) emulate the behaviour (mind the locking problems don't bite you though). (1) On the desktop install WinCVS and checkout modules and update the repository as locally mounted. (2) Connect the laptop to desktop CVS server, checkout some modules and disconnect the laptop. OK Now when the laptop is on the "go", I would like to change the modules but **under CVS control**. For this purpose, I will bring the checked out modules to a local repository using WinCVS. CVS doesn't work like that. You check your modules in when you connect back into the LAN. I suspect it could be arranged to have multiple repositories (with a program to fudge the 'Root' files), but it'd get very confusing very fast (how would you keep the version numbers in sync, for example). Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: trouble with 'release' command in NT
Dennis Jones wrote: Tony, cvs -t gives: - run_popen(cvs/cvs -n -q -d 192.168.0.21:/vol/cvs update,r) The name specified is not recognized as an internal or external command, operable program or batch file. cvs release: unable to release 'CVSROOT' This looks wrong. Firstly it's trying to run 'cvs/cvs', secondly the cvsroot is wrong (192.168.0.21:/vol/cvs is not a valid cvsroot). Also I don't see how an NT version could *ever* generate a path of 'cvs/cvs'. It's generated from argv[0]. What are you using to run cvs? Some kind of wrapper program? I can't see a way of generating this data without hardcoding it into a program somewhere. Are you using some kind of 3rd party shell (cygwin?). The cvs release command looks to be implemented pretty badly anyway, so this is a bug waiting to happen... It tries to re-execute cvs with a 'cvs update' command. Really it needs fixing in the core. However it definately works on a standard system. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: Laptop CVS setup
Andy Glew wrote: BitKeeper is apparently becoming popular with Open Source projects such as the LINUX kernel. The Bitkeeper people *wanted* it to become popular with the linux kernel, even going as far as donating copies to various people. However AFAIK bitkeeper is still vapour, and the linux kernel people continue in their good old fashioned 'emailing patches to linus' source control method. Anyway, bitkeeper is (will be) just another commercial source control system. It's in competition with all the other ones out there... Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: trouble with 'release' command in NT
Dennis Jones wrote: I am able to use the 'cvs release -d' command in Linux and Win98, but in WinNT, I get the following error message: The name specified is not recognized as an internal or external command, operable program or batch file. cvs release: unable to release 'CVSROOT' It sounds like you have a commitinfo or loginfo with an invalid command in it. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: problems with CVS on NT
Eitle Jürgen wrote: Hi, I am trying to use CVS on NT. The repository is mounted locally, i. e. it is not a client/server set up. Now, when developer 1 has committed a file and developer 2 updates this file, makes some changes, and wants to commit the file I get a very disturbing error message. Checking in footer_part.jsp; //Geneve/ew3/cvsroot/c2000/footer_part.jsp,v -- footer_part.jsp You are probably using the 'stock' cvs.exe. This is a cvs 'unixism' which is mostly fixed on the cvsnt version (it tries to delete read-only files). Try that version and see if you get the same. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: Need shlwapi.dll for wincvs
Michael Gersten wrote: I have NT 4, service pack 6, but I seem to be missing ShlwApi.dll, which wincvs needs. Where can I get this dll? I had an earlier version of WinCvs (1.0.6), but uninstalled it to use 1.1b13; that needs this dll. This is part of the system DLLs (the 'shell lightweight API'). If it's been deleted on your system I expect it's on the install CD. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: Problem for locking
Frédéric PREVOST wrote: Hello, I've downloaded and installed both CVSNT 1.10.8 and WinCVS 1.1b13. Everything works fine. But, i tried to use the lock (cvs admin -l) option on WinCVS but the response I recieved is : "cvs [admin aborted]: usage is restricted to members of the group CVSAdmin" Is this on an an NT server? The check is currently commented out on the NT version (because checking membership of an arbitrary group is undocumented in NT4), and has been for some time Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: [Fwd: CVSNT: Notes on case sensitivity problems in NT]
Alexey Milov wrote: The problem is not only with the edit command, but with the fact, that filename comparisions with the repository are not case sensitive (hash.c if I remember). Have a look at elevener.cjb.net, I believe that patch in CASE.TXT decides this and some other Win32 case problems. Putting fncmp in hash.c looks like it does the trick (this looks like it's basically what the patch does)... Other stuff in there has been dealt with already. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
[Fwd: CVSNT: Notes on case sensitivity problems in NT]
This is probably fixable, but rather than get lost in the 'cvs edit' code, I though I'd post it here... Has anyone seen this before and fixed it? Tony Original Message Subject: CVSNT: Notes on case sensitivity problems in NT Date: Tue, 9 May 2000 13:21:16 -0700 From: Tad Hetke [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" [EMAIL PROTECTED] Tony, I am doing some research on CVS and came upon an interesting case sensitivity issue that has not been addressed as of the 1.10.8 release. Since I have no compiler as yet (ordered...but not waiting for it), I thought I would send you the description on the off chance that you may have found and addressed this already. If you do these steps, the problem should become clear. cvs add junk cvs commit junk cvs edit junk cvs edit Junk At this point, if you look in $CVSROOT/CVS/fileattr, you will see that two attribute records have been added for the file "junk". One with an upper case 'J'. Upon commit, only one is removed. This makes problems with respect to any scripts that may rely on the contents of fileattr. Here is what I believe is happening. Somehow, cvs is accepting the case insensitive filename and passing it to the routines in edit.c as whatever the string is on the command line. This seems to be a problem in the fn* routines that handle sensitivity. Here is what I think should be done. It seems to me that when cvs discovers that a file is being accessed, it should simply use the name from the file itself, not the string passed in by the user. This will work beautifully on systems like NT where case is preserved, but not enforced. This will allow cvs internals to use the file in a case sensitive manner (as it does already), while removing the requirement that the user get the right case on the edit command. There may be other commands that have this problem, so I think modification of the command itself could be inappropriate. Tad Hetke Senior RTOS Engineer Oresis Communications (503) 466-6318
Re: Problems with check-in and Samba
Larry Jones wrote: The ,filename, file is where commit writes the new RCS file. Once it's been successfully written, CVS renames it to filename,v to replace the old RCS file. I've seen this one... CVS doesn't check the read-only status of the old file when it renames it, so you get the error. On Windows, you need delete access to the file to delete it, not the directory (Win95/98 don't even have a directory permissions bit). Essentially it needs a wrapper to unlink() which calls SetFileAttributes() then DeleteFile() to mimic the Unix behaviour. Tony
Mailing list for CVS server for NT
I have setup a mailing list for users of the CVS server for NT. This is for NT specific problems (setup, bugs, etc.). 'General' cvs stuff should of course still go to [EMAIL PROTECTED] See http://www.cvsnt.org/mailman/listinfo/cvsnt Tony (this is of course a thinly veiled attempt to reduce the amount of mail I get in my inbox...) -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: Could timestamps be replaced with MD5?
Martin Roehrig wrote: As I already wrote in a previous posting I think it is really a good idea. Right now I have seen a problem in it: CVS Windows clients automatically convert text file line endings from LF to CRLF and vice versa. So checksums computed on a Windows client will bedifferent from checksums computed on the (*nix) server. (I don't know how the WinNT CVS server stores textfiles.) Not a problem - The CVS client/server protocol specifies unix file sementics for text files, so only the client has to worry about the CRLF problem (and it presumably already knows whether it's the windows version or not...) Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: CVS history command (cvsnt server)
Arthur Barrett wrote: Any further assistance will be most appreciated! OK I think I've nailed the problem. Try the latest version, and see if it works for you. Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: How to generate a ChangeLog file from CVS?
Mark Derricutt wrote: On Mon, 10 Apr 2000, Ronald Henderson wrote: http://www.red-bean.com/~kfogel/cvs2cl.shtml I was wondering if there's a ChangeLog script available that works under NT/95 against a pserver? Oddly, this is one of the few scripts that works without modification under NT (OK you have to remove the spurious 'exec' at the top, but other than that it works fine). Tony -- #define QUESTION ((bb) || !(bb)) - Shakespeare [EMAIL PROTECTED]
Re: Setting up CVS password on NT
Ñarendra Acharya wrote: Hi everybody, I need to set up CVS for accepting user-id and password on NT in the cvs.html its been written as follows: On the server side, the file `/etc/inetd.conf' needs to be edited so inetd knows to run the command cvs pserver when it receives a connection on the right port. By default, the port number is 2401; it would be different if your client were compiled with Do you (a) want a Unix server to authenticate from an NT domain controller? AFAIK this would require a PAM-enabled version of CVS, which hasn't been done yet. ..or (b) want to run the server on NT? Download the NT server from http://betty.magenta-logic.com/cvs, and install/run it (see readme.nt). Once it's installed and running as a service it's essentially the same operation as per the standard documentation. Tony -- [EMAIL PROTECTED]
Re: sending mail via CVS on an nt server...
Hamid Ghassemi wrote: Has anyone tried to have cvs send e-mail via blat.exe? We have cvs installed on windows NT server using pserver. I am trying to modify loginfo to send e-mail after each commit on a windows NT server and am not successfull. any help is greatly appreciated. It works fine, however you have to do a fair abount of hacking with the default commit_prep/log_accum.pl files before they can run under NT. If you just want to call blat.exe loginfo (you get an email for each directory modified), it's documented in the CVS manual (just replace 'mail' with 'blat') Tony -- [EMAIL PROTECTED]
Spaces in filenames?
How is cvs supposed to handle spaces in filenames? At the moment I have a big problem with the loginfo scripts failing because the repository name has a space in it... Is there a way to change it so it'll handle this situation (I've also had several odd bug reports in the NT server which suggest that the commits are sometimes failing with spaces in the pathnames, although I haven't been able to replicate it). I thought of changing loginfo parameters so they are comma separated... then you have the same problem, but with commas instead of spaces (although commas are far less common in filenames than spaces). Tony -- [EMAIL PROTECTED]
Re: Viewing/Browsing a remote repository
Brendan Simon wrote: How can one view the repository to see the available modules ? I tried "cvs co -c" and "cvs co -s" but nothing was returned. I haven't got a modules file in the CVSROOT directory. Must I have one of these ? Surely there must be a way to browse the repository so that a nice UI can be used to select a module and perform a checkout and other cvs functions. Probably not an ideal solution, but I cheated. I put everything in subdirectories in the module 'Develop'. CVS allows you to checkout individual subdirectories, and it keeps the boss happy... Tony -- [EMAIL PROTECTED]
Re: Unix to Dos filtering
Stephen L Arnold wrote: Wrong. I distinctly remember the samba guys (Allison Tridgell) saying they didn't want samba to attempt any such conversion. From the samba docs: Hmm... There is a FAQ (must dig it out if I can find it) that specifically mentions that smbfs honours the 'conv=' options line FAT does. I have had this problem myself, with files coming out differently when you read them through smbfs than when you read them on a windows machine. I generally FTP between unix and windows these days because the corruption problems are a nightmare (not to mention smbfs suddenly dropping the connection in the middle of a file copy and hanging the 'cp' process). Generally SMB mounts will only stay 'alive' for half an hour or so, then they will die. You have to unmount/remount to wake them up again. I know a lot of stability problems have been fixed recently, and maybe it's better now, but I still wouldn't recommend trying to access a repository through it. Tony -- Swamp frog: ribb-it ribb-it ribb-it Busch frog: bud..wis..er bud..wis..er Win95 frog: Re-boot Re-boot Re-boot [EMAIL PROTECTED]
Re: Unix to Dos filtering
[EMAIL PROTECTED] wrote: Dear CVS Gurus, Client developers on my site, checkout code on unix machines. They then use the checked out code on Windows using Samba. How do i make sure that when they check the files out on unix, it automatically put the Ctrl Ms on these DOS-type files? If a file is checked in with Ctrl Ms on unix, are the Ctrl Ms retained on another checkout or during commit? (All cvs commands are run on unix). Thanks in advance, aditya If the files are checked in in 'Microsoft format' on the Unix boxes, you must never attempt to subsequently check them out from a microsoft box as it will get very confused (It will get lots of CRCRLF pairs and attempt to double the number of lines in the source file). Why not just use the microsoft client, which will strip the extra CR characters out, and put them back in again? Much of the same caveats exist re: sharing over samba as sharing over NFS, only worse (samba has this habit of attempting to convert text files itself unless you stop it...) Tony -- Swamp frog: ribb-it ribb-it ribb-it Busch frog: bud..wis..er bud..wis..er Win95 frog: Re-boot Re-boot Re-boot [EMAIL PROTECTED]
Re: CVS Server on NT
Wayne Johnson wrote: When I attempt to connect to the new server I get: D:\share\CVS Server NT\bin.\cvs -d:pserver:goldenrod:c:\cvsroot co -s cvs checkout: CVSROOT ":pserver:goldenrod:/cvsroot" is not fully-qualified. cvs [checkout aborted]: Please make sure to specify "user@host"! Ahh found a typo in readme.nt. You were following my instructions rather too exactly :-) Sorry 'bout that. Tony -- "Now you too can enjoy having babies... start collecting today" (Recent advert) [EMAIL PROTECTED]
Re: CVS Server on NT
Wayne Johnson wrote: I've installed the CVS server on NT binaries, created the cvs repository (cvs -d c:\cvsroot init), added the PServer registry entry, and installed and started the ntserver. When I attempt to connect to the new server I get: D:\share\CVS Server NT\bin.\cvs -d:pserver:goldenrod:c:\cvsroot co -s cvs checkout: CVSROOT ":pserver:goldenrod:/cvsroot" is not fully-qualified. cvs [checkout aborted]: Please make sure to specify "user@host"! Looks like the cvs client won't accept your new pserver syntax. Any suggestions? That is incorrect syntax for :pserver: -- did you mean to use :ntserver:? Tony -- "Now you too can enjoy having babies... start collecting today" (Recent advert) [EMAIL PROTECTED]
Re: 'I HATE YOU' too terse?
Tobias Weingartner wrote: I HATE YOU sounds pretty good. I really don't see why we need to "enhance" this part of CVS. I think in client-server mode, there should be a log file which gives better information. Maybe in CVSROOT? Maybe in RCS,v format, so that you can do a 'cvs log' on the file, and get a history of who did what? Maybe a 'cvs get' will give the log message of the checkin (if it was a checkin), or some other indication of which files were affected. Actually separating 'bad user' from 'bad cvsroot' has halved the number of tech. support requests I get overnight... A user logging feature would be better, though - some sort of utmp-a-like (although it should be in text format). This information should not be available through the client, though, since it defeats the object of keeping the 'I HATE YOU' response. Tony -- It's official - the Unixverse ends on Tue Jan 19 03:14:07 2038 [EMAIL PROTECTED]
