Re: Restricting users from creating a new repository.
Gagneet Singh wrote: Hi! Would anybody know of a way to restrict users on the CVS server from creating a repository via the client? You have to patch the sources. I have included a patch for the SuSE-8.1-version. Hope it helps. Regards, Stephan cvs-1.11.1p1-217.dif Description: Binary data ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Using CVS to maintain XML
Wayne Johnson wrote: ... Anyone know a good way to manage XML in CVS? Is there a program that will sort an XML file? To make sure that similar tags always appear in the same order? Am I just dreaming? ... You could use a stylesheet, i.e. XSL (http://www.w3.org/Style/XSL/), and sort your tags with xsl:sort. There are a lot of XSL processors, e.g. sablotron (http://www.gingerall.com/). Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Modify administrative files upon commit
Hello Stefano, Stefano Costa wrote: Dear readers of this list, I have this problem: I'm using a few scripts (perl mainly) that are called before commit (specified inside commitinfo) and I'd like to maintain these scripts along with the other CVSROOT administrative files. So I added their names to checkoutlist and they are correctly checkout after commit into $CVSROOT/CVSROOT. But I didn't find a way to modify their attributes so that they are set executable *after* having been checkout, any idea? ... You could explicitly invoke the interpreter in the commitinfo file; to invoke myscript.sh arg1 arg2 you would have to write /bin/sh myscript.sh arg1 arg2. This method should work with other scripting languages, too. Hope that helps Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: multiple cvs clients operating on same working directory
Hello David, David Fuller wrote: Are you talking clients as in software, or clients as in people? If people then it is a bad idea, if software then it doesn't matter. I mean clients in the sense of more than one cvs executable running at the same time. On Tue, 19 Feb 2002, Stephan Feder wrote: Hello, is it safe to run multiple cvs clients that operate on the same working directory (for example one does a checkin and another does a checkout)? TIA Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: multiple cvs clients operating on same working directory
Hello David, David Fuller wrote: What condition could you be in where you would be running those two commands concurrently? Just think about a cron job that regularly updates my working directory and that starts the very moment I am accessing the repository on the terminal. I am not so much worried about the final state of my working directory as about things getting lost or corrupted. If for example I checkout the same module twice at the same time, will I end up with a working copy of that module and correct meta information that describes that very working copy, or will I end up with garbage only? On Tue, 19 Feb 2002, Stephan Feder wrote: Sorry, perhaps I did not state my question correctly so maybe the following example clarifies what I want to know: Suppose I invoke cvs update and cvs commit concurrently in the same working directory. Do these two clients get mixed up or do they synchronize their access to the working directory and the CVS subdirectory? I know that concurrent access to the repository is not a problem but what about the working directory? Stephan -- Stephan Feder wrote: Hello, is it safe to run multiple cvs clients that operate on the same working directory (for example one does a checkin and another does a checkout)? TIA Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Abort while checking out
Hi Raghav, Datla, Raghav wrote: ... cvs [server aborted]: out of memory; can not reallocate 79691776 bytes ... You ran out of main memory (including virtual memory like swap space): you need at least the file's size of main memory on the client and three times the file's size of main memory on the server... bad implementation. Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
multiple cvs clients operating on same working directory
Hello, is it safe to run multiple cvs clients that operate on the same working directory (for example one does a checkin and another does a checkout)? TIA Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: multiple cvs clients operating on same working directory
Sorry, perhaps I did not state my question correctly so maybe the following example clarifies what I want to know: Suppose I invoke cvs update and cvs commit concurrently in the same working directory. Do these two clients get mixed up or do they synchronize their access to the working directory and the CVS subdirectory? I know that concurrent access to the repository is not a problem but what about the working directory? Stephan -- Stephan Feder wrote: Hello, is it safe to run multiple cvs clients that operate on the same working directory (for example one does a checkin and another does a checkout)? TIA Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: after Cygwin update, CVS authorization fails
john lukar wrote: The problems is that cvs checkout works in other directories other than the e:\projects directory. when I use the command line cvs that came with WinCVS, I can operate on e:\projects without a problem. It seems that they provide a modified version of the command line cvs. the cvs version with my cygwin setup (clien/server 1.11) version is problematic. Is there anyway to fix it? The command line cvs from WinCVS supports the switch --lf which means using LF instead of CR/LF for text files (there is an option in the GUI as well). If you always work in that mode you should be able to share the working directory between Unix and Windows (we had no problem so far). when You say use one sandbox for each, do you mean I should not switch between WinCVS and bash-cygwin cvs while working on a project directory? Yes, that is what it means. As outlined above you do not have to live with that solution. TIA for input. You are welcome Stephan -- --- Stephan Feder [EMAIL PROTECTED] wrote: What you see (mangling) is a CR after john so the start of the follwing line (probably cvs server: au is hidden on screen). Seems you have checked out a text file under Windows (WinCVS) and now under Unix (Cygwin) the CR is not recognized as end of file (instead of a checked out file it could also be any file in the CVS subdirectories). Essentially that means: Use one sandbox for working under WinCVS and another one for Cygwin. If this advice/solution does not please you... that is the result of the thread with subject WINCVS and MSVC problem on this very list. Regards Stephan -- john lukar wrote: I just did an update to my cygwin installation which includes the cvs client as well. after doing so, I can no longer login and checkout to our cvs server. my cvs client version using cvs -version says: Concurrent Versions System (CVS) 1.11 (client/server) the peculiar thing is that, when I change to another directory e.g. e:\temp, then I can do all of my cvs operations including login and checkout of modules. It is only the e:\projects directory that is creating this problem for me. This is where I maintain all of my cvs managed projects, even prior to my cygwin upgarde. Also my failure message says: thorization failed: server mycvsserver rejected access to /share/CVS. As you can see the user name johnthoriztion is mangled. My cvs login d is john, but the au part of authorization is dropped and prefixed with my name. I can jCVS and WinCVS to manager this same directory e:\projects. I seems to be only the cygwin cvs client that is a problem. thanks much john. any ideas? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
default entry in cvswrappers
Hello, I would like to define -kb as default in cvswrappers and then list only file types that should be treated as text, like this: * -k 'b' *.rtf -k 'kv' -m 'COPY' *.RTF -k 'kv' -m 'COPY' *.txt -k 'kv' -m 'MERGE' *.TXT -k 'kv' -m 'MERGE' Will this work as defined, do I have to reorder entries, and are the patterns case sensitive? Thanks Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: after Cygwin update, CVS authorization fails
What you see (mangling) is a CR after john so the start of the follwing line (probably cvs server: au is hidden on screen). Seems you have checked out a text file under Windows (WinCVS) and now under Unix (Cygwin) the CR is not recognized as end of file (instead of a checked out file it could also be any file in the CVS subdirectories). Essentially that means: Use one sandbox for working under WinCVS and another one for Cygwin. If this advice/solution does not please you... that is the result of the thread with subject WINCVS and MSVC problem on this very list. Regards Stephan -- john lukar wrote: I just did an update to my cygwin installation which includes the cvs client as well. after doing so, I can no longer login and checkout to our cvs server. my cvs client version using cvs -version says: Concurrent Versions System (CVS) 1.11 (client/server) the peculiar thing is that, when I change to another directory e.g. e:\temp, then I can do all of my cvs operations including login and checkout of modules. It is only the e:\projects directory that is creating this problem for me. This is where I maintain all of my cvs managed projects, even prior to my cygwin upgarde. Also my failure message says: thorization failed: server mycvsserver rejected access to /share/CVS. As you can see the user name johnthoriztion is mangled. My cvs login d is john, but the au part of authorization is dropped and prefixed with my name. I can jCVS and WinCVS to manager this same directory e:\projects. I seems to be only the cygwin cvs client that is a problem. thanks much john. any ideas? __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com ___ 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: WINCVS and MSVC problem
Kaz Kylheku wrote: In article [EMAIL PROTECTED], Stephan Feder wrote: Larry, I know how the cvs client handles line endings but nonetheless it is a problem for quite a few users. What about a flag for the client that prevents it from doing _any_ line ending conversions (as I understand it the server transfers the files as they are)? You misunderstand. The problem is that some idiots took DOS text files sitting on a Linux client, and imported or added them to CVS. That means everyone with a working directory shared between windows and unix boxes (not shared between multiple users!) is an idiot? Do you really think having two working directories with the same (apart from line endings) checked out revisions is clever? And if you (have to) switch between systems while editing a file you have to check in system 1's file and update system 2's file. And you have to back it up. And just maybe the proper line ending for editing is not the proper line ending for processing. This is not a CVS problem at all. It's a problem between the keyboard and chair. If you have a bunch of text files, and they are correctly represented text files for the operating system you are using, you can put them into CVS. Someone can check them out on a different operating system, and CVS will convert them to proper text files for that operating system. When you add or import files, you can specify that they are to be treated as binary. Binary files don't undergo line ending conversions. Binary files also cannot be merged and do not undergo keyword substitution. Whether a file is text or binary is an essential, inherent property of that file. It's not something you want to be turning on and off at transport time. Well, you can easily switch between binary and the different text modes (option -k) but in my eyes there are 3 properties: 1. should the file be merged, 2. should keywords be substituted, 3. should line endings be converted. I would like to have 1 and 2 without 3. Is this idea so ridiculous? One solution in your case is to check out the erroneous files, fix their broken line endings, and commit the changes. Changing the client behavior on checkout is the wrong solution to the wrong problem. One more note about sharing working directories between systems: If you checkout under Windows you cannot work under Unix simple because the \r in the CVS directories' files are interpreted as being part of the Repository/Root. I am a little bit afraid of being told the obvious reason for that. Regards Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs [export aborted]: cannot export into a working directory
Hello, exporting part of a repository with cvs -d :fork:/repository export -Dnow module/submodule fails (same with :ext:) with server message cvs [export aborted]: cannot export into a working directory but cvs -d :local:/repository export -Dnow module/submodule succeeds (client/server 1.11 on Linux). I am using a separate LockDir and TopLevelAdmin=yes in config, and access to certain top level subdirectories of the lock directory and the repository is restricted by group rights, but other cvs commands do not take offense. Anyone any idea? Regards Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: WINCVS and MSVC problem
Larry, I know how the cvs client handles line endings but nonetheless it is a problem for quite a few users. What about a flag for the client that prevents it from doing _any_ line ending conversions (as I understand it the server transfers the files as they are)? Regards Stephan -- Larry Jones wrote: =?ISO-8859-15?Q?J=F6rg_R=FCppel?= writes: I have some sourcefiles in my Linux cvs repository. When I check them out with WinCVS through pserver and try to open them with MSVC, MSVC states that it has detected lines ending on CR. In fact, the lines in the checkedout file end up with CR CR LF, all of them. The original file on another computer only contains CR LF. When I copy this file directly to the MSVC system, it works without problems. Could someone tell me where the additional CR comes from and how I can get rid of it? That's what happens when you check in files that end with CRLF on a system where text files end in just LF (e.g., checking in Windows files on Unix). CVS thinks the CR is part of the line rather than part of the terminator. Then when you check the files out on a system that does use CRLF terminators, you get the CR that's part of the line followed by the CRLF line terminator. The way to avoid this problem is to never edit or check in a file on a different system than the one it was checked out (or, for new files, created) on. And never share working directories between different systems. -Larry Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SSH and WinCVS
Hi Jack, I had a similar problem with openssh on linux (SuSE distribution). After upgrading openssh everything just worked fine. So maybe you could just try the newest version of client and server side ssh. Stephan -- Jack Baty wrote: Hi, I hope this isn't too far OT... I'm successfully using WinCVS (1.3.6.1 Beta 6) on two Win2000 machines. Connection is via SSH to a repository on FreeBSD. I'm running into a problem connecting from a third machine (Win2000 also). I'm fairly certain I've followed the WinCVS documentation properly, but the key is being refused by the server. Here's the output when using the -v option in WinCVS (only the host and user names have been modified)... SSH Version 1.2.14 [winnt-4.0-x86], protocol version 1.4. Standard version. Does not use RSAREF. ssh_connect: getuid 0 geteuid 0 anon 0 Connecting to host.domain.com [208.xxx.xxx.xxx] port 22. Connection established. Remote protocol version 1.99, remote software version OpenSSH_2.3.0 FreeBSD localisations 20010713 Waiting for server public key. Received server public key (768 bits) and host key (1024 bits). Host 'host.domain.com' is known and matches the host key. Initializing random; seed file C:\Documents and Settings\user\My Documents/.ssh/random_seed IDEA not supported, using 3des instead. Encryption type: 3des Sent encrypted session key. Received encrypted confirmation. Trying RSA authentication with key '[EMAIL PROTECTED]' Server refused our key. Doing password authentication. ...then it hangs until I force the DOS window closed. Any idea what I may be missing? -- Jack Baty Fusionary Media - http://www.fusionary.com/ ___ 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: --allow-root and init via SSH
Hi Greg, what I meant was specifying --allow-root on the server side. Otherwise users could easily circumvent the restriction. If you specify :ext: on the client side the ssh server just calls login -c 'cvs server' (login is your shell as in /etc/passwd). What I did is entering my own little program in /etc/passwd which, if called with the arguments mentioned above executes 'cvs --allow-root repository server' but this does not have any effect. There is a patch available for that problem (just search the list archive) but AFAIK it is not incorporated into the mainstream sources. Regards Stephan -- Gerhard Sittig wrote: On Tue, Dec 11, 2001 at 13:12 -0500, Larry Jones wrote: Greg A. Woods writes: Is --allow-root evaluated for cvs server in the current development version, or is it at least on the todo list? Now you're really asking for trouble. [ ... slight misreading :) ... ] He was speaking of the CVS --allow-root= option that specifies (for pserver) what the allowable CVSROOT directories are. So, *is* the --allow-root option evaluated for the cvs server case? I did a very quick test lately trying to restrict access to one of two repos but still was allowed to access both of them. Since I'm not absolutely positive that I did everything right, could somebody please verify or deny that it's worth to try this combo (:ext: plus --allow-root)? BTW: This would be one reason less pushing people towards the :pserver: method. And being ortoghonal(sp?) cannot be wrong. : 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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: --allow-root and init via SSH
Hi Larry, would it be a pain to just add it? The patch is already there and if the default behaviour (i.e. in the case when no --allow-root is set) were to allow access to any repository it would be backward compatible, so no problem there. Regards, Stephan -- Larry Jones wrote: Gerhard Sittig writes: So, *is* the --allow-root option evaluated for the cvs server case? No, it is only used for :pserver:. Historically, the user was in complete control of the server command line, so it didn't make any sense to try to use its contents to control what the user was allowed to do. Even with SSH, it has to be set up very carefully or it's totally ineffective. I haven't yet heard an overwhelming demand to change it. -Larry Jones That's one of the remarkable things about life. It's never so bad that it can't get worse. -- Calvin ___ 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
--allow-root and init via SSH
Hello, I want to set up CVS in a way so that some dedicated cvs users cannot do anything hostile. For that reason they have to login via SSH and their login shell is a simple program that checks that they want to execute cvs server and then executes cvs server itself. But now a simple cvs -d :ext:user@host:/tmp/any name init allows those users to pollute the /tmp directory (or any other directory they are allowed to write to, even within an existing repository they have access to). Should not creating new repositories be disallowed via remote access? Another question I asked some time ago on this list: Is --allow-root evaluated for cvs server in the current development version, or is it at least on the todo list? Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
