RE: cvswrappers - any better suggestions ?
Quite often these days, CVS is not something that you choose -- you get chosen by CVS, much as you get chosen by Microsoft operating systems and development tools, simply because it's ubiquitous. Like it or not, there's not much respect for original design goals in the ways of the world. I suppose that 'full RCS compatibility' is not a goal by itself -- if you might as well use RCS, then why use CVS? I'd like to bring attention to one particular offspring of cvs: subversion. Have a look at http://subversion.tigris.org/. The project is near it's second major milestone, and plan to have an alpha release mid May and a 1.0 release late June. BTW, here's another way to use currently available features (aka cvswrappers) to avoid the poor loosers munging their binary files: Rather that listing patterns for known 'binary' files, you list patterns for known 'text' files, but default to binary, like this: # text formats *.[Tt][Xx][Tt] *.[Xx][Mm]][Ll] *.[Cc] #default is binary * -k 'b' Remember that cvswrappers doesn't work if you connect to the repository using a remote protocol (e.g. pserver); you must put a copy of the 'cvswrappers' file named '.cvswrappers' into each users home directory. Kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Saturday, 31 March, 2001 2:19 AM To: Gianni Mariani Cc: [EMAIL PROTECTED] Subject: RE: cvswrappers - any better suggestions ? [ On Friday, March 30, 2001 at 07:07:14 (-0800), Gianni Mariani wrote: ] Subject: RE: cvswrappers - any better suggestions ? Your point is well taken. However, time are a changing - source code is not only text. Image, sound, movie, geometry, encryption key, etc etc files are all parts of modern day applications. All these files need to be version managed just like regular files. If we could apply an rcsmerge on these kinds of files, then it would be ideal. Yes, what you say is all very well and fine. What it means though is that CVS is not the correct tool for use in such a diverse environment. Obviously my point did not sink in properly though so I will say it more clearly: PLEASE go use something else snip ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers - any better suggestions ?
"Greg A. Woods" wrote: [ On Sunday, April 1, 2001 at 08:26:32 (-0800), Gianni Mariani wrote: ] Subject: RE: cvswrappers - any better suggestions ? Your discussion below exposes a perspective which is about as far off from my own as you can get. I will go as far to say that your goals are You people just don't get it. CVS adheres to design principles that are completely contrary to your requirements. You CANNOT succeed with it given your current goals! It's irrelevant how many users have made the wrong choice and are using CVS despite the fact that its design is contrary to their goals. A wrong choice is wrong no matter which side you look at it from. Nope; CVS adheres to design principles that are at least somewhat compatible with our requirements. The fact that people are using CVS for the management of binary files implies that somebody can do it and be successful. Nor do I understand why this is inherently a wrong choice. I can understand why it would be the wrong choice under some given circumstances, but I have a great deal of difficulty with moral absolutes in open-source software. Please go find some other software to abuse, and hopefully this time you'll choose some non-free software and you'll be able to pay it's maintainers to change their design if it doesn't happen to fit your goals! Maybe you'll be lucky and you'll choose some non-free software that has a significant "market share" too. Philosophically, this seems to be a Platonist approach to software tools, and you're in a community of Aristotelians. What this means is that I believe we don't have archetypes of programming tools, in which CVS is judged on its similarity to the archetype of program source control systems, but a whole lot of existing tools, which are judged on certain criteria (philosophically more accidental than essential) such as usefulness. I apply this sort of philosophy for other tools, also. I don't wonder about how screwdrivery a screwdriver is, but rather how easily it turns screws and how durable it's likely to be. Given a paint can, I don't go to the hardware store and buy a tool to open paint cans, I pry off the lid with a screwdriver. It isn't designed to open paint cans, is not intended to, and is not sold for the purpose. I would assume it's harder to remove a lid without bending it with a screwdriver than with a specially designed tool (with a screwdriver, you have to pry gently around the lid). However, I have screwdrivers and a place to put them. I don't want to buy and store a special paint can lid opening tool. Heck, I don't even want to write to tool manufacturers and tell them that they need to make screwdrivers more paint-can-lid compatible. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers - any better suggestions ?
Remember that cvswrappers doesn't work if you connect to the repository using a remote protocol (e.g. pserver); you must put a copy of the 'cvswrappers' file named '.cvswrappers' into each users home directory. Actually it does now. It changed somewhere around 1.10. Mike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs pserver and knowing who did what
Hi, At work I've installed cvs and we now have a cvs repository which all developers access through the pserver. All accounts are mapped to the same userid (so the CVSROOT/passwd file is user:passwd:cvsaccount for every user). When I use the loginfo method to automatically send mail about the commits, the "Author" is always set to 'cvsaccount'. Is there any way to make this the 'user' entry? I'm just using an example log.pl script, but I printed the environment settings, and that also didn't have any knowledge of the 'user' name. Any ideas? Greetings, Chris Niekel -- Geek code version 3.1: GCS d- s++: a- C++$ ULSI++ P+(---) L+++ E--- W++ N++ o K? w--- O M- V?-- PS+ PE-() Y PGP+ t 5? X- !R tv+ b DI++ D+ G++ e+++ h--- r+++ y+++ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
--- Forwarded mail from [EMAIL PROTECTED] The goal of CVS is to to *exactly* what it does and has always done That's it. Nothing more. Nothing less. If this were really true, then the developers of CVS would have packed up and gone home long ago. CVS continues to evolve, but not in the directions that some of us would like to see. CVS didn't always have a client/server implementation, for example. The fundamental design of CVS can accomodate many features discussed in this forum, many of them more readily than a client/server implementation. CVS will survive in exactly the places where it fulfills the requirements it was designed to fulfill. If those requirements ever completely go away, or if any other tool comes along that fulfills those requirements in an obviously better way, then maybe CVS will cease to "survive", but that'll be a good thing and we'll all rejoice when it happens! If you put CVS into organisations where it won't do anything but confuse them and cause them troubles because it's the wrong tool for their requirements then you're doing the WRONG thing! It's no damn wonder that sometimes you fail to convince some clients to use CVS! They don't all NEED it You fail in those cases because you have failed to understand their requirements and to correctly do the job they hired you to do! CVS, like all software, is very maleable. Like any software tool, it can, and it should, evolve to suit the needs of its users (and not the other way around). There are limits to how far CVS can go while retaining its identity and its niche, but it has a long way to go before it begins to challenge them. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
[ On Sunday, April 1, 2001 at 14:00:20 (-0700), David Glick wrote: ] Subject: RE: cvswrappers - any better suggestions ? BTW, I *do* get it; I just don't agree with you. I've spent most of 20+ years listening to people just like you explain why something shouldn't/couldn't be done, and then finding ways to make it happen anyway. Clearly, other people feel the same way, because CVS does support binary files after a fashion. I just want them supported better. Clearly you do not get it at all. CVS literally cannot support binary files in any better fashion without becoming something that will no longer be a "Concurrent Versions System". It was designed specifically to force concurrent editing and that design goal permeates the way it works through and through (despite the valiant attempts by others to bend it to suit their twisted ideas). You cannot throw out the bath water without throwing out the baby in this case -- they are one in the same. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: restoring an old repository
=?euc-kr?B?sO0gv7XIrQ==?= writes: After OS installation job, I tryed to re-load the previous data. But I can't. I don't know what's matter. What shall I do in this case ? Tell us exactly what you did and exactly what error messages you got. How do you expect people to help without any details? -Larry Jones I'm so disappointed. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Patches: cvs --allow-root=/blah server
I'm a bit stumped as to where patches for this should go. We're looking at running CVS here using :ext:-mode access and ssh, and using sshd's command="cvs --allow-root=/blah server" option to limit people to only runing CVS. Currently the CVS server I have access to (1.11-derived) doesn't honour the --allow-root option for "cvs server": I've some small patches at http://ioctl.org/unix/cvs/ to get CVS to do so. Could you have a look at these for potential inclusion against the next release? They're against the vendor copy included with FreeBSD but ought to fit with the stock release. Cheers, jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED] (Things I've found in my attic, #2: A hundredweight of pornography.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
Unfortunately, there are enough members of the CVS community who just don't seem to understand the necessity of many proposed features, and who are influential enough to defer or even actively discourage their introduction. Examples of such needed features include full support of non-ASCII file types, directory versioning, more complete and robust refinement triggers, and even a generalized merge tool registrar. These things have been discussed for years in this forum, and numerous implementations have been discussed. Nevertheless, the preference to apply 1988's technology to 2001's programming problems remains compelling for some. Unfortunately, there does not seem to be sufficient interest to either accept such new features into the mainstream, or to splinter off a new development effort to produce a more capable tool. RCVS was one attempt to open up and encourage development of new things, but it didn't work out as was hoped. So, you have the following choices: Design and build CVS v2.0 from the ground up and make it a useful tool. Cripple your software development effort enough that the existing CVS can handle it. Use something else. Using something else is the fastest and easiest way to get what you want (and the cheapest in the long run), but crippling your current process may be the fastest and easiest way to overcome some immediate hurdle and limp along until the next crisis arises. --- Forwarded mail from [EMAIL PROTECTED] With all due respect, Greg, I think Gianni made some very telling points which CVS will need to address if it is to survive. I'm an independent consultant, and I try to bring CVS into each organization I work with. I'm sometimes successful, but I fail at times for exactly the reasons Gianni articulates. With the proliferation of MSWord, IDE project files, etc, no reasonable person can argue that non-text files are not a necessary part of most projects these days. If CVS does not 'grow up' and attempt to support the new development environments, it will slowly be replaced by something that does, and CVS will ultimately become a bit player, promoted by a few fanatic users who try to make its case at every opportunity (whether appropriate or not), and ignored or laughed at by the majority of the population. I've heard your same arguments applied to Forth, OS/2, Geos, Clarion, Lotus 1-2-3, Wordstar, UCSD P-System... the list goes on. I'd hate to add CVS to the list. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
Peter, you say: "Remember that cvswrappers doesn't work if you connect to the repository using a remote protocol (e.g. pserver); you must put a copy of the 'cvswrappers' file named '.cvswrappers' into each users home directory." I have evidence to the contrary. I just tested it using :pserver: . BTW - I love the default binary cvswrappers. That is exactly what I was looking for. I should have figured that out sooner, it's obvious. I would like the file check before checking in though ! Anyone have a cool list of all text file extensions ? G -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Ring Sent: Sunday, April 01, 2001 11:52 PM To: CVS-II Discussion Mailing List Subject: RE: cvswrappers - any better suggestions ? Quite often these days, CVS is not something that you choose -- you get chosen by CVS, much as you get chosen by Microsoft operating systems and development tools, simply because it's ubiquitous. Like it or not, there's not much respect for original design goals in the ways of the world. I suppose that 'full RCS compatibility' is not a goal by itself -- if you might as well use RCS, then why use CVS? I'd like to bring attention to one particular offspring of cvs: subversion. Have a look at http://subversion.tigris.org/. The project is near it's second major milestone, and plan to have an alpha release mid May and a 1.0 release late June. BTW, here's another way to use currently available features (aka cvswrappers) to avoid the poor loosers munging their binary files: Rather that listing patterns for known 'binary' files, you list patterns for known 'text' files, but default to binary, like this: # text formats *.[Tt][Xx][Tt] *.[Xx][Mm]][Ll] *.[Cc] #default is binary * -k 'b' Remember that cvswrappers doesn't work if you connect to the repository using a remote protocol (e.g. pserver); you must put a copy of the 'cvswrappers' file named '.cvswrappers' into each users home directory. Kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Saturday, 31 March, 2001 2:19 AM To: Gianni Mariani Cc: [EMAIL PROTECTED] Subject: RE: cvswrappers - any better suggestions ? [ On Friday, March 30, 2001 at 07:07:14 (-0800), Gianni Mariani wrote: ] Subject: RE: cvswrappers - any better suggestions ? Your point is well taken. However, time are a changing - source code is not only text. Image, sound, movie, geometry, encryption key, etc etc files are all parts of modern day applications. All these files need to be version managed just like regular files. If we could apply an rcsmerge on these kinds of files, then it would be ideal. Yes, what you say is all very well and fine. What it means though is that CVS is not the correct tool for use in such a diverse environment. Obviously my point did not sink in properly though so I will say it more clearly: PLEASE go use something else snip ___ 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 pserver and knowing who did what
Hello, Do the developers also have UNIX accounts? Then don't use the CVSROOT/passwd file, I don't think there's any really good reason to use it. It's easier to set up a phony shell that doesn't allow logins and use the UNIX user account system if you don't want people logging into the box. Of course, if you don't have root or don't want to do this then you'll have to wait for someone with more experience with loginfo to reply ;) HTH, Rob Helmer On Mon, Apr 02, 2001 at 01:28:07PM +0200, Chris Niekel wrote: Hi, At work I've installed cvs and we now have a cvs repository which all developers access through the pserver. All accounts are mapped to the same userid (so the CVSROOT/passwd file is user:passwd:cvsaccount for every user). When I use the loginfo method to automatically send mail about the commits, the "Author" is always set to 'cvsaccount'. Is there any way to make this the 'user' entry? I'm just using an example log.pl script, but I printed the environment settings, and that also didn't have any knowledge of the 'user' name. Any ideas? Greetings, Chris Niekel -- Geek code version 3.1: GCS d- s++: a- C++$ ULSI++ P+(---) L+++ E--- W++ N++ o K? w--- O M- V?-- PS+ PE-() Y PGP+ t 5? X- !R tv+ b DI++ D+ G++ e+++ h--- r+++ y+++ ___ 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: How to specify port with `cvs pserver'?
Hello, Well, if I was using CVS from remote and SSH was installed on the server side, and I had a UNIX account on the server side, I would set these environment variables : CVS_RSH=ssh CVSROOT=:ext:user@host:/path/to/repository Then do "cvs command". If I wanted to use pserver for some reason, I would first make an SSH tunnel : ssh -L 2401:localhost:2401 user@host Then use this CVSROOT: CVSROOT=:pserver:user@localhost:/path/to/repository The SSH tunnel makes it look like port 2401 ( the CVS port ) is open on the local host. I usually use the first method, the second method only requires that you enter your password once to open the tunnel, and again to do "cvs login", while the first will ask for your password everytime you do a CVS command. HTH, Rob Helmer On Sun, Apr 01, 2001 at 03:22:45PM +0200, Kai Gro?johann wrote: I can't access the outside directly, so I use port forwarding via ssh. So if I want to access two `cvs pserver' repositories, I have to set up port forwarding with two different local ports, right? I guess that means I need to specify the port on the remote host when doing cvs -d :pserver:user@host:/path/to/repository command How do I do that? kai -- Be indiscrete. Do it continuously. ___ 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: cvswrappers - any better suggestions ?
David H. Thornley writes: Nope; CVS adheres to design principles that are at least somewhat compatible with our requirements. The fact that people are using CVS for the management of binary files implies that somebody can do it and be successful. Nor do I understand why this is inherently a wrong choice. I can understand why it would be the wrong choice under some given circumstances, but I have a great deal of difficulty with moral absolutes in open-source software. People successfully use hammers to insert screws. That doesn't mean a hammer is the right tool (or even a good tool) for the job. Heck, I don't even want to write to tool manufacturers and tell them that they need to make screwdrivers more paint-can-lid compatible. But that's exactly what you're doing with CVS. -Larry Jones Wh. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS pserver
I'm new to this and am attempting to set up a pserver on a linux box which will service multiple windows machines running wincvs. I have thus far installed cvs and created a repository. I'm not sure how to actually get pserver listening on the port I'm using. Any help on what command line needs to be added to what file would be greatly appreciated. From reading I found that the line goes to the inetd.conf file but I can't find it on RH7.0. Thanks Charles
Re: cvs pserver and knowing who did what
Chris Niekel writes: When I use the loginfo method to automatically send mail about the commits, the "Author" is always set to 'cvsaccount'. Is there any way to make this the 'user' entry? I'm just using an example log.pl script, but I printed the environment settings, and that also didn't have any knowledge of the 'user' name. You have to pass the username ($USER) explicitly from the loginfo file -- that's why the example log.pl script has a -u option. See the loginfo example in the manual: http://www.cvshome.org/docs/manual/cvs_18.html#SEC170 -Larry Jones I told her to expect you to deny everything. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Patches: cvs --allow-root=/blah server
Jan Grant writes: I'm a bit stumped as to where patches for this should go. We're looking at running CVS here using :ext:-mode access and ssh, and using sshd's command="cvs --allow-root=/blah server" option to limit people to only runing CVS. Since sshd ends up running as the real user, why don't you just use Unix permissions to restrict people to the appropriate repositories? -Larry Jones The hardest part for us avant-garde post-modern artists is deciding whether or not to embrace commercialism. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
Greg's statement below is flatly untrue. We've discussed this very topic at length in this forum many times in the past. His argument is based on the fact that the RCS "merge" tool cannot support merges of arbitrary file formats. It doesn't even support merges of arbitrary ASCII formats. And yet, the CVS community attempts to use it in that capacity all the time. There are application-specific merge tools for numerous file formats, some of which are useful for software development. Others don't exist but can be written without great effort. When all else fails, there's always the trivial binary or trinary file selection algorithms. And don't forget that there are the many existing text-based merge tools that people prefer using, such as the one supplied with Emacs. Inserting a registrar into CVS to allow shops and users to specify the particular tool required to perform a merge is not a fundamental change to the CVS design, but it is a small generalization. And it's one that will greatly benefit the CVS community in general. Such a mechanism does NOT affect in the slightest way ANY aspect of the concurrent development model that CVS implements. (It is basically just parameterizing the hard-coded path to the RCS-supplied merge tool, or its equivalent in the librified RCS.) --- Forwarded mail from [EMAIL PROTECTED] [ On Sunday, April 1, 2001 at 14:00:20 (-0700), David Glick wrote: ] Subject: RE: cvswrappers - any better suggestions ? BTW, I *do* get it; I just don't agree with you. I've spent most of 20+ years listening to people just like you explain why something shouldn't/couldn't be done, and then finding ways to make it happen anyway. Clearly, other people feel the same way, because CVS does support binary files after a fashion. I just want them supported better. Clearly you do not get it at all. CVS literally cannot support binary files in any better fashion without becoming something that will no longer be a "Concurrent Versions System". It was designed specifically to force concurrent editing and that design goal permeates the way it works through and through (despite the valiant attempts by others to bend it to suit their twisted ideas). You cannot throw out the bath water without throwing out the baby in this case -- they are one in the same. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
I'd argue that I do get it; you just don't get that I get it. Your statement "CVS literally cannot support binary files..." should be changed to "CVS does not currently support binary files in a way that is consistent with the philosophy of concurrent editing". If we can agree with the above statement, then this immediately leads to two possible approaches (or three, if you continue to argue that binary files should not be supported...): 1) Violate the 'concurrent' philosophy with regard to binary files, and implement a locked checkout to allow for straightforward creation of deltas and avoid the messy problems of figuring out how to concurrently update binary files. 2) Allow for concurrent checkout of binary files, but disallow concurrent commits, e.g. only a user that has updated to the current version will be allowed to commit changes. Neither approach is ideal, but both provide a step in the direction of better support for binary files. I'm sure there are other approaches that may well satisfy other people's needs, too. There may even be a way to fold binary file support completely into the CVS philosophy; I'm just too busy right now to think it through completely (and, unfortunately, I'm *way* to busy to actually do the work... sigh.). - Original Message - Clearly you do not get it at all. CVS literally cannot support binary files in any better fashion without becoming something that will no longer be a "Concurrent Versions System". It was designed specifically to force concurrent editing and that design goal permeates the way it works through and through (despite the valiant attempts by others to bend it to suit their twisted ideas). You cannot throw out the bath water without throwing out the baby in this case -- they are one in the same. - Original Message - ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
[ On Monday, April 2, 2001 at 01:13:35 (-0700), Paul Sander wrote: ] Subject: RE: cvswrappers - any better suggestions ? If this were really true, then the developers of CVS would have packed up and gone home long ago. CVS continues to evolve, but not in the directions that some of us would like to see. CVS didn't always have a client/server implementation, for example. Hmm... I think you're mixing up your history with present day here. The CVS developers did pack up and go home. Even the ones who picked up the torch after them have themselves packed up and gone home long ago. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
[ On Monday, April 2, 2001 at 01:02:26 (-0700), Paul Sander wrote: ] Subject: RE: cvswrappers - any better suggestions ? Unfortunately, there are enough members of the CVS community who just don't seem to understand the necessity of many proposed features, and who are influential enough to defer or even actively discourage their introduction. Paul haven't you ever wondered why that's so? Perhaps you've got it backwards. I would suggest that there are enough non-members of the CVS community who are jealous of the CVS community and would rather twist, rip, tear, mould, spindle, and otherwise manipulate the CVS community so that they can join it without changing their own ways. Examples of such needed features include full support of non-ASCII file types, directory versioning, more complete and robust refinement triggers, and even a generalized merge tool registrar. These things have been discussed for years in this forum, and numerous implementations have been discussed. Nevertheless, the preference to apply 1988's technology to 2001's programming problems remains compelling for some. That's because most true programming is still done with 1970's technology and so something neat-o-nifty and new like CVS is highly applicable to most of our daily work and actually makes us more productive. I doubt there would be any *BSD releases if it were not for CVS being exactly what it is! So, you have the following choices: Design and build CVS v2.0 from the ground up and make it a useful tool. Cripple your software development effort enough that the existing CVS can handle it. Use something else. Hear! Hear! Three cheers for Paul! Now could all you people who don't like the way CVS is designed please follow his helpful suggestions? -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
[ On Monday, April 2, 2001 at 08:51:31 (+0200), Peter Ring wrote: ] Subject: RE: cvswrappers - any better suggestions ? Quite often these days, CVS is not something that you choose -- you get chosen by CVS, much as you get chosen by Microsoft operating systems and development tools, simply because it's ubiquitous. Like it or not, there's not much respect for original design goals in the ways of the world. Fortunately CVS is anything but ubiquitous. Even within the open source world (whatever the heck that is! :-), CVS is not the choice of all the masses (and of course it's never been the only choice). I suppose that 'full RCS compatibility' is not a goal by itself -- if you might as well use RCS, then why use CVS? The issue has more to do with keeping the repository in a standard format. This is of enormous importance in assuring backward and forward compatability. A repository is literally something that keeps all of your eggs in one basket. If you start messing with the weave on that basket without first removing the eggs then you're as likely to have them all drop right out the bottom. One other reason to do this is so that should someone who has a better idea, and the time to implement and support it, come along then he/she can be assured that pulling stuff out of any given CVS repository without having to write custom code to handle what would effectively become a proprietary (well open, but unique) and possibly changing format. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Can Wincvs use rsh (:server:) connection method?
I hear you, but then why does Wincvs give that error?
("Set the password authentication first in the preferences !")
Oh, and how can I make it stop giving this error?
Thanks and Best Regards
Steve
At 07:13 AM 3/30/2001 -0700, you wrote:
Steve,
The point is that there is no password using rsh. It uses your IP and login
name (the name you use to login in your Windows box).
Regards,
alex.
- Original Message -
From: "Steve Rabin" [EMAIL PROTECTED]
To: "Alexandre Parenteau" [EMAIL PROTECTED]
Sent: Thursday, March 29, 2001 7:11 PM
Subject: Re: Can Wincvs use rsh (:server:) connection method?
Hi Alex:
I am not trying to log in. I am trying to figure out how
to tell the rsh method handler built into Wincvs what password
to use in order to make the error
"Set the password authentication first in the preferences !"
go away.
Thanks and Best Regards,
Steve
At 05:19 PM 3/29/2001 -0700, you wrote:
Steve,
You don't login for rsh, you just set-up a ~/.rhosts file in the user
account of the server machine.
Regards,
alex.
- Original Message -
From: "Steve Rabin" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, March 29, 2001 1:25 PM
Subject: Can Wincvs use rsh (:server:) connection method?
Is it possible to convince Wincvs to use the rsh (:server:) connection
method
rather than the pserver method described in the Wincvs docs? I don't
want
to
have to mess with sysadmin to change the inetd. I am willing to limit
use
to trusted machines listed in rhosts. When I try setting the method to
server
I keep getting the message:
Set the password authentication first in the preferences !
But I can't seem to figure out what to click on to tell Wincvs what
password
to use with this rsh method.
Thanks and Best Regards,
Steve
___
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: cvswrappers - any better suggestions ?
[ On Monday, April 2, 2001 at 09:56:28 (-0500), David H. Thornley wrote: ] Subject: Re: cvswrappers - any better suggestions ? Philosophically, this seems to be a Platonist approach to software tools, and you're in a community of Aristotelians. No, you Aristotelians are invading a community where you don't belong. What this means is that I believe we don't have archetypes of programming tools, in which CVS is judged on its similarity to the archetype of program source control systems, but a whole lot of existing tools, which are judged on certain criteria (philosophically more accidental than essential) such as usefulness. Hmm Indeed that's about the current state of software engineering, and in particular software configuration management. Unfortunately the entire industry has a lot to learn about SCM, and even the academic community just barely have academic ideas about how all of this stuff is supposed to work. CVS is, BTW, just one tiny part of the toolset necessary to help automate SCM, and it's not particularly good as such tools go either. However it fits the basic mold of Unix software development very well and as such it has helped the Unix world achieve a higher level of SCM and to become more productive as a result. Other tools might have been even more successful at meeting these goals, but either they weren't in the right place at the right time, or they are not yet invented. I apply this sort of philosophy for other tools, also. I don't wonder about how screwdrivery a screwdriver is, but rather how easily it turns screws and how durable it's likely to be. Given a paint can, I don't go to the hardware store and buy a tool to open paint cans, I pry off the lid with a screwdriver. It isn't designed to open paint cans, is not intended to, and is not sold for the purpose. I would assume it's harder to remove a lid without bending it with a screwdriver than with a specially designed tool (with a screwdriver, you have to pry gently around the lid). However, I have screwdrivers and a place to put them. I don't want to buy and store a special paint can lid opening tool. Funny, but around here the paint cans come with their own opening tool (which co-incidentally is a multi-purpose tool that also opens the beer bottles you'll be handing around to all the friends you've invited over to help you paint! :-) Most stores hand out two for every can! :-) Indeed the reason there are people prying versions of binary files out of their CVS repositories is because people generally do just choose to use the first thing that drops into the palms of their hands instead of taking the time to find the right tool for the job. Unfortunately in the more virtual world of software engineering people are incredibly bad at making even roughly correct estimates in how much time they might save, or how much more productive they might be, by choosing the first tool that appears in front of them instead of doing a proper analysis and searching for the right tool. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
[ On Monday, April 2, 2001 at 11:22:32 (-0700), Paul Sander wrote: ] Subject: RE: cvswrappers - any better suggestions ? Greg's statement below is flatly untrue. We've discussed this very topic at length in this forum many times in the past. His argument is based on the fact that the RCS "merge" tool cannot support merges of arbitrary file formats. Well, sort of. It's a little deeper than that, of course. It doesn't even support merges of arbitrary ASCII formats. Well, no, but that's partly the point! ;-) And yet, the CVS community attempts to use it in that capacity all the time. And with remarkable success, success that's been scientifically documented ever since CVS-II was released. Indeed there are several other tools with the same basic design for support of concurrent editing and they are equally successful. Of course programmers who have used CVS for a long time will inherently learn little tricks that make actual merge conflicts even less likely to occur except where absoutely necessary. Indeed there are even programming tricks that can make accidental hidden conflicts less likely. And of course the CVS source itself provides a half-decent example of the benefits of automated product testing. Inserting a registrar into CVS to allow shops and users to specify the particular tool required to perform a merge is not a fundamental change to the CVS design, but it is a small generalization. Yes, but one that would require a rather drastic revision to the repository format. And it's one that will greatly benefit the CVS community in general. I'm not so sure. If it were so it would have been done long ago and offered back to the community. As it is we don't even have a sample implementation to show to the community and to prove that such a forward change in the repository format would succeed. Such a mechanism does NOT affect in the slightest way ANY aspect of the concurrent development model that CVS implements. (It is basically just parameterizing the hard-coded path to the RCS-supplied merge tool, or its equivalent in the librified RCS.) I agree whole-heartedly. I'm just not restricting my view to one set of concerns -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Triggers links to defect tracking systems
Hi, Is there any facility in CVS to add hooks for customized actions? For instance, requiring a Bug Number when you check in a file, verifying that bugnum against your defect tracking system, etc. If not are there any projects underway to address this? Thanks ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
--- Forwarded mail from [EMAIL PROTECTED] Inserting a registrar into CVS to allow shops and users to specify the particular tool required to perform a merge is not a fundamental change to the CVS design, but it is a small generalization. Yes, but one that would require a rather drastic revision to the repository format. And it's one that will greatly benefit the CVS community in general. I'm not so sure. If it were so it would have been done long ago and offered back to the community. As it is we don't even have a sample implementation to show to the community and to prove that such a forward change in the repository format would succeed. co -p common-ancestor-revision file .file.base co -p other-contributor file .file.contrib my-merge-tool --base .file.base --contributor .file.contrib file This algorithm can be easily implemented with CVS (in fact, I believe it already is). And it does not require any change to the repository format, other than providing a means to specify what my-merge-tool really is. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
