Re: cvswrappers - any better suggestions ?
Echlin, Michael [EMAIL PROTECTED] writes: There are problems with binary files in cm. when you start adding many revisions to an archive you get an archive file that suddenly becomes very large, with some documents having a size of 6 to 20 megs even 10 revisions is a large file to hunt through to get at the particular version of the document, and with our particular industry the documents are live for the life of the system they describe and that life expectancy is 40 years. This may not be the case for the document processor program you're using, but many word processors allow saving in .RTF format, which is a text file. People using such a word processor (MS Word is an example) could just save all their documents in that format, which should greatly reduce the size of diffs between revisions. That and let me specify what program I will use to show the diff of that type of file. (Word does diffs of word files, excel does diffs of excel files...) I know how to make Word show me a diff of two files from the menu, but don't know how to do it from a DOS commandline, and I've been *dying* to find out (I could then setup tkCVS to use it); I even searched the MSDN documentation and didn't find anything. Do you (or anybody else on the list) know how to do this? Note that subversion (http://subversion.tigris.org) *will* have support for diff plugins, I believe both for viewing and for storing (not sure about the 2nd). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
I know I am getting into this one about an eon to late but here's my 2 cents worth. We are a company that while we do create code wew normally create documents. Our current use of CM tools in various projects and divisions is all over the mapo from tools that cost tens of thousands a seat to rcs and cvs for free. In any one project you will find one tool in use because using more then one is just a waste of time. So we want a tool that can handle our code well and also our documents well. Unfortuantly the documents are in the company standard word processor and so are binary. One of the current CM tools handles binary files way different them it handles text files. There are problems with binary files in cm. when you start adding many revisions to an archive you get an archive file that suddenly becomes very large, with some documents having a size of 6 to 20 megs even 10 revisions is a large file to hunt through to get at the particular version of the document, and with our particular industry the documents are live for the life of the system they describe and that life expectancy is 40 years. This soon makes management of this file very hard due to file size. This tool does things a little different. It creates an archive for the document by creating a sub-directory (only for binary, for text it uses the same old RCS file) and keeps each copy of the file there individually the name of the file being stored with each rev stored with the number (1.1) as the name of that version of the file, and keeps the ,v file where it always has been, but this file contains everything else about the file such as log history, ... I think this might be a good adition to the way cvs handles binary files. That and let me specify what program I will use to show the diff of that type of file. (Word does diffs of word files, excel does diffs of excel files...) Mike. -Original Message- From: Alexander Kamilewicz [mailto:[EMAIL PROTECTED]] Sent: April 6, 2001 10:39 AM To: David H. Thornley Cc: CVS-II Discussion Mailing List Subject: Re: cvswrappers - any better suggestions ? David H. Thornley wrote: Here's the situation I'm looking at. We do most of our work in conventional programming languages like C++ and Java and Perl, and these work very well with CVS. We use HTML for some documentation, and that generally works well (although I have little experience with CVS storing the abominations you get when saving as HTML from Word). We have things like release branches and patch branches. What this means is that CVS works very well for most of the stuff we do. On the other hand, there is stuff mixed in there that is not source code. One example would be image files for the HTML. These files are most conveniently located in the same directory as the HTML files, and in some cases source files. This is very similar to my environment, although as well as images we have lots of .mov, .fla, .swf, .doc, .xls, assorted binary files. This means that we have three choices. 1. Continue to use CVS, accepting the problems with binary files. 2. Use a combination of CVS and some other system that handles binary files better. 3. Switch to another tool entirely. We do #1. The only problem with #1 is that you're going to have a repository that grows rather rapidly. We realized that and invested in a Network Appliance. My repository is now 33Gb large. However, since the bulk of our problems with binary files is: Here's a new version of that image/movie/flash/whatever, have fun we decided that it would be pointless, at this point, to move to another SCM tool when CVS fits so well into the toolkit of the developers doing the .htm, .jsp, and .js files. I think it's worth noting that one of the pre-eminent SCM tools for version control/management of images/flash/movies, called MediaWay, doesn't store diffs but stores a copy of every version of every element ever entered into and/or modified in its repository. That's basically what CVS does. So CVS isn't particularly far away from that functionality. If you have a need for a tool that provides more and better information on complex binary files (images/flashes/movies), then you can do what we do. Buy MediaWay, have the graphics dudes use it, and use cvs import when they have new versions. It works OK for us. Alex ___ 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" wrote: Here's the situation I'm looking at. We do most of our work in conventional programming languages like C++ and Java and Perl, and these work very well with CVS. We use HTML for some documentation, and that generally works well (although I have little experience with CVS storing the abominations you get when saving as HTML from Word). We have things like release branches and patch branches. What this means is that CVS works very well for most of the stuff we do. On the other hand, there is stuff mixed in there that is not source code. One example would be image files for the HTML. These files are most conveniently located in the same directory as the HTML files, and in some cases source files. This is very similar to my environment, although as well as images we have lots of .mov, .fla, .swf, .doc, .xls, assorted binary files. This means that we have three choices. 1. Continue to use CVS, accepting the problems with binary files. 2. Use a combination of CVS and some other system that handles binary files better. 3. Switch to another tool entirely. We do #1. The only problem with #1 is that you're going to have a repository that grows rather rapidly. We realized that and invested in a Network Appliance. My repository is now 33Gb large. However, since the bulk of our problems with binary files is: "Here's a new version of that image/movie/flash/whatever, have fun" we decided that it would be pointless, at this point, to move to another SCM tool when CVS fits so well into the toolkit of the developers doing the .htm, .jsp, and .js files. I think it's worth noting that one of the pre-eminent SCM tools for version control/management of images/flash/movies, called MediaWay, doesn't store "diffs" but stores a copy of every version of every element ever entered into and/or modified in its repository. That's basically what CVS does. So CVS isn't particularly far away from that functionality. If you have a need for a tool that provides more and better information on complex binary files (images/flashes/movies), then you can do what we do. Buy MediaWay, have the graphics dudes use it, and use cvs import when they have new versions. It works OK for us. Alex ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
[[ Could you please learn to format your text so that it can be properly displayed on the average terminal? Thanks! ]] Since I'm using an Open Source mail agent (which I'm trying to find time to contribute to), I'll take this as an enhancement request and add it to the list... g 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...): No, unfortunately we cannot agree on that statement. It is wrong (in fact it's completely self-contradictory!), and it points out why you're "not getting it" (at least to me). Well, you're right this time; I don't get it. How is my statement contradictory? 1) Violate the 'concurrent' philosophy with regard to binary files, 1) and implement a locked checkout to allow for straightforward 1) creation of deltas and avoid the messy problems of figuring out how 1) to concurrently update binary files. That's what plain RCS, plain SCCS, and other basic tools built atop of them do today. There's a multitude of such tools, both freely available and proprietary. If this is your approach then drop CVS and choose one of those tools. You cannot make CVS do #1 without changing it into something that cannot be a "CVS". (Indeed the watch/edit facilities can help developers who fail to work in the "concurrent editing" mode communicate, especially when they haven't already got other good ways of communicating amongst themselves. These features are not a substitue for #1 though and they only help a tiny bit with the binary file issues.) Greg, what you're arguing here is that it is impossible for #1 to be implemented without changing the repository. I agree. However, it is certainly feasible that this change would be fully backward compatible with the repository as it exists today. Of course, it's also true that the repository would *not* be 'forward compatible', e.g. you could not use an old CVS server on a new repository with regard to binary files. However, I disagree with the notion that I should drop CVS for something that supports binary files better. I *like* the way CVS supports source code editing; I think it makes development groups *more* productive. But binary files are almost always an annoying problem in most modern development environments that I have to find a way to deal with. The current support CVS has for binary files is ok, but not great. Better binary support, even if it fails to fully support the 'concurrent' philosophy, would at least allow me to leverage the benefits of CVS for what it does best. 2) Allow for concurrent checkout of binary files, but disallow 2) concurrent commits, e.g. only a user that has updated to the 2) current version will be allowed to commit changes. That's exactly what CVS does now. The problem is with the "update" part. CVS currently forces the burden of choosing between one version and another on the "loser" of the checkin race. Perhaps you can educate me here. I was under the impression that CVS did not supports deltas when dealing with binary files, but rather copied the modified binary file completely. Is this not accurate? Neither approach is ideal, but both provide a step in the direction of better support for binary files. If you don't like the tradeoffs of #2 then don't use CVS. Period. Or else modify CVS to better meet my needs, assuming that it also meets the needs of other users and doesn't impact its use by 'old timers'. Now, if nobody but myself would find these modifications useful, I fully agree I should go find something else to use. However, in the short amount of time I've been monitoring this list, this issue seems to come up a lot. You can argue that it's because those people are newbies and don't 'get it'. I'd argue that it's because CVS is flawed in this instance. There may even be a way to fold binary file support completely into the CVS philosophy; You really should read the relevant threads in the past four or five years of this forum before you promote such a mistaken idea! ;-) g I'll add it to my reading list. However, you're doing a great job in summarizing the arguments. I'm just curious if I'm rehashing old argurments or coming up with anything new. 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.). I can appreciate that. However it's no excuse though for blaming CVS for being designed the way it is. It's not even really a valid excuse for using CVS when some better tool would make your work more productive. I'm not blaming CVS; as I said, I *like* CVS, and I fully buy into its general development
Re: cvswrappers - any better suggestions ?
Hi, One VC product I've seen that uses an RCS-ish back end handles binary files approximately as follows: At the time they are created in the database (repository), they are examined for a presence of certain nonprintable ascii characters. If these are found, the file is marked in the database as binary and handled as such from then on. It's not perfect, but works right about 99.9% of the time without the user having to explicitly specify binary/text. Diff and merge are still available, and fail on some binary content, as they probably should. So the concurrent editing part is lost for binaries (not that I've ever team-edited a gif file), but at least the central repository and versioning remains. I agree with someone's observation that most projects are no longer pure text. -- Bruce Tiffany
Re: cvswrappers - any better suggestions ?
"Greg A. Woods" wrote: [ 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. Y'know, it can be really difficult to figure out whether you're surrounded by Platonists or Aristotelians. Funny, but around here the paint cans come with their own opening tool They do? I've always used the screwdrivers. (Am I buying my paint in the right places?) 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. Here's the situation I'm looking at. We do most of our work in conventional programming languages like C++ and Java and Perl, and these work very well with CVS. We use HTML for some documentation, and that generally works well (although I have little experience with CVS storing the abominations you get when saving as HTML from Word). We have things like release branches and patch branches. What this means is that CVS works very well for most of the stuff we do. On the other hand, there is stuff mixed in there that is not source code. One example would be image files for the HTML. These files are most conveniently located in the same directory as the HTML files, and in some cases source files. This means that we have three choices. 1. Continue to use CVS, accepting the problems with binary files. 2. Use a combination of CVS and some other system that handles binary files better. 3. Switch to another tool entirely. Realistically, (2) isn't going to fly. CVS and the other system would have to be too closely intertwined, and nobody wants to learn another SCM system. This leaves (1) and (3). The problem with (3) is that CVS is very good for most of what we do. We need things like branches and concurrent development, and the fact that it has been working for a long time with few problems. Our source code is the company's most valuable asset (not counting people). Reliability and confidence are good things for this. If we were to go to another system, we would not have the same trusting feeling, and would go through a learning curve. I'm not saying we're going to use CVS forever, but any replacement needs to have much the same features as CVS or productivity is going to take a real hit. So, if somebody can point to a SCM system that has the same reliable reputation, doesn't cost too much, and does the same sorts of things, I'm listening. Otherwise, in a world where none of the tools exactly match my needs, I'm going with what seems to me the best choice, and right now that's CVS. -- 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 ?
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
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: 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: 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
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: 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
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
RE: cvswrappers - any better suggestions ?
Greg, We heard you already - we just don't agree with you. There is very little point saying the same thing over again. rant type=philosophical disposition="ignore if uninterested" WE (TM) (the philosophical WE) each have our different goals, there is absolutly no reason for them to be the same and MANY reasons for them to be different. 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 very different to most that are using CVS today. I will stretch even further and say that there are about as many different goals users have for CVS as there are CVS users. So, when YOU (TM) (the philosphical YOU) find everyone else is doing the Wrong Thing (TM) you might find it fruitless and more often negative to convince THEM (TM) otherwise. A more productive approach may be to accept that THEY (TM) are just different. It does not mean you have to agree with THEM (TM). It does mean however you stop arguing with once THEY (TM) acknowledge and reject your point of view. /rant BESTOLUCK G -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Saturday, March 31, 2001 11:28 AM To: CVS-II Discussion Mailing List Subject: RE: cvswrappers - any better suggestions ? [ On Saturday, March 31, 2001 at 05:57:31 (-0800), David Glick wrote: ] Subject: RE: cvswrappers - any better suggestions ? 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. Come on you guys CVS's goal is not to "survive", whatever the heck that could possibly mean in a free software community! Survival and market share are not just oxymorons to free software, but in fact are dangerous concepts that can only damage good free software (look at the horrible mess in things like Mozilla, KDE, and even most GNU/Linux distributions!). The goal of CVS is to to *exactly* what it does and has always done That's it. Nothing more. Nothing less. 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! PLEASE learn to understand your requirements and learn to use the right tool for the right job. You do not use a hammer to turn in screws and you do not modify your hammer to make it look like a screwdriver because if you do then you won't have a hammer any more! You've got absolutely NO excuse for using the wrong FREE tools!! We do NOT need any false CVS evangelists who preach it as a hammer for all screws It is already a monopoly in the niche it fits in, and if you can't figure out what niche that is then don't evangelise it (and you probably shouldn't even use it either)! (and yes I do use Mozilla -- it's the best free software of its type that I've been able to find and it fills more of my requirements than anything else like it) -- 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 ___ 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 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 very different to most that are using CVS today. I will stretch even further and say that there are about as many different goals users have for CVS as there are CVS users. 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. 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. -- 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 ?
Don't be silly, Greg; abusing other software wouldn't be nearly as amusing... 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. Because I respect someone as certain of themselves as you are (even if you're wrong), I'll let you know what the answer is when I find it. David Glick Transmit Consulting, Inc 619-475-4052 [EMAIL PROTECTED] - Original Message - [ 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 very different to most that are using CVS today. I will stretch even further and say that there are about as many different goals users have for CVS as there are CVS users. 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. 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. -- 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 - Original Message - ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
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. David Glick Transmit Consulting, Inc 619-475-4052 [EMAIL PROTECTED] - Original Message - --- snip --- [ 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 --- - Original Message - ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
[ On Saturday, March 31, 2001 at 05:57:31 (-0800), David Glick wrote: ] Subject: RE: cvswrappers - any better suggestions ? 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. Come on you guys CVS's goal is not to "survive", whatever the heck that could possibly mean in a free software community! Survival and market share are not just oxymorons to free software, but in fact are dangerous concepts that can only damage good free software (look at the horrible mess in things like Mozilla, KDE, and even most GNU/Linux distributions!). The goal of CVS is to to *exactly* what it does and has always done That's it. Nothing more. Nothing less. 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! PLEASE learn to understand your requirements and learn to use the right tool for the right job. You do not use a hammer to turn in screws and you do not modify your hammer to make it look like a screwdriver because if you do then you won't have a hammer any more! You've got absolutely NO excuse for using the wrong FREE tools!! We do NOT need any false CVS evangelists who preach it as a hammer for all screws It is already a monopoly in the niche it fits in, and if you can't figure out what niche that is then don't evangelise it (and you probably shouldn't even use it either)! (and yes I do use Mozilla -- it's the best free software of its type that I've been able to find and it fills more of my requirements than anything else like it) -- 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 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 Here is some interesting work in this area: http://www.cs.berkeley.edu/~jmacd/xdelta.html Yes, and I was aware of it well before most of the rest of the community was, but CVS does not xdelta, and in fact cannot without breaking it's current design goal of keeping the repository fully RCS compatible. (note that even though RCS can store binary files, CVS cannot deal properly with RCS'ed binary files in its repository. CVS runs on top of RCS, not the other way around!) We both agree, cvswrappers is a band aid at best. No, if that's what you think then we do not agree. Cvswrappers are a mistake that misleads users into thinking CVS is something that it just cannot be. They can only cause problems. They should never ever have been added to the "official" release. They should in fact be removed before the next major release is made, if indeed anyone ever gets brave enough tot make a "major" release. If some poor user can't find a way to do without them or to use some other more appropriate tool then that user is free to maintain his or her own local version of CVS with them still integrated, and since CVS is free software that user is free to make either the patches or the integrated release freely available too. As to MYSELF developing a new versions management system, there are plenty of people doing that, I would just confuse the situation. If you were to build a tool that filled your needs explicitly, and then freely offered it to the world, just as the authors of CVS and CVS-II originally did, then perhaps you'd clarify things. If not then perhaps you should become an early adopter of whichever of these other new systems you think will in fact actually meet your explicit requirements. The reason I choose CVS is because it is prolific, people I hire are likely going to know about the system. I'd rather fix CVS itself - that is if I get time to do it - along with my 100 other unfinished projects. Then you chose CVS for exactly the wrong reasons and as a result you made the wrong choice because you ignored the fact that it does not meet your real requirements. CVS is not something that tries to gain market share at all costs -- quite the opposite as it is free software that very nicely and properly fills *one* niche in the software configuration management tool set. Because it is free software you are free to mis-use it, but you'd be better off realising that you're also free not to use it at all. Choosing CVS because you percieve that it has market share despite the fact that it obviously does not meet your real requirements demonstrates that you do not understand how to make effective use of free software! Demanding that CVS properly handle binary files either demonstrates that you do not understand your own requirements or you do not understand the goals of free software and the reasons why a tool like CVS would be made freely available. My suggestion to you, as you offered so many to me, is to think about a broader use of CVS as not only a concurrent versions/merging tool but also as a database off all components that are used to build products Excuse me, but CVS is not anything but a *source* code control tool that was *explicitly* designed to support, nay to force, the ability for its users to concurrently edit source files! Anyone who tries to use it for something else, will inevitably run into problems such as you have. - some of which are not text; that I need to version successfully and satisfies the ACID semantics (Atomicity, Consistency, Isolation, and Durability). Then you absolutely need something that is not CVS. Period. -- 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 ?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Friday, March 30, 2001 4:19 PM To: Gianni Mariani . . . Obviously my point did not sink in properly though so I will say it more clearly: PLEASE go use something else We clearly violently disagree, obviously there is no point in further discussion. Cheers G ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers - any better suggestions ?
Hello, Well, I won't ask why you want ot check any of this stuff into CVS ;) You can just do this : *.[Dd][Oo][Cc] to cover all possible capitalizations of .doc files, for instance. HTH, Rob Helmer On Thu, Mar 29, 2001 at 09:26:06AM -0800, Gianni Mariani wrote: I want to kinda set and forget my cvswrappers file. I have a mixed Win/unix dev environment and I want to set and forget which file are binary and which are not. SO - I created the following cvswrappers file (all ~700 extensions) that are most likely binary. I got it by scanning my Win drives for all extensions, running 'file' on them and removing any extensions which 'file' reported as 'text'. Any better ideas ? Is this a dumb ass thing to do ? cvswrappers *.386 -k 'b' *.3GR -k 'b' *.3gr -k 'b' *.603 -k 'b' *.850 -k 'b' *.852 -k 'b' *.866 -k 'b' *.ACG -k 'b' *.acg -k 'b' *.ACL -k 'b' *.acl -k 'b' *.ACM -k 'b' *.acm -k 'b' *.ACS -k 'b' *.acs -k 'b' *.ACT -k 'b' *.act -k 'b' *.ADP -k 'b' *.adp -k 'b' *.ADV -k 'b' *.adv -k 'b' *.AFM -k 'b' *.afm -k 'b' *.AHQ -k 'b' *.ahq -k 'b' *.AIF -k 'b' *.aif -k 'b' *.ANI -k 'b' *.ani -k 'b' *.AP0 -k 'b' *.ap0 -k 'b' *.API -k 'b' *.api -k 'b' *.APP -k 'b' *.app -k 'b' *.APS -k 'b' *.aps -k 'b' *.ATI -k 'b' *.ati -k 'b' *.AVB -k 'b' *.avb -k 'b' *.AVI -k 'b' *.avi -k 'b' *.AW -k 'b' *.aw -k 'b' *.AWX -k 'b' *.awx -k 'b' *.AX -k 'b' *.ax -k 'b' *.AX_ -k 'b' *.ax_ -k 'b' *.BDR -k 'b' *.bdr -k 'b' *.BFONT -k 'b' *.bfont -k 'b' *.BLEND -k 'b' *.blend -k 'b' *.BM_ -k 'b' *.bm_ -k 'b' *.BMP -k 'b' *.bmp -k 'b' *.BS -k 'b' *.bs -k 'b' *.BSC -k 'b' *.bsc -k 'b' *.BTR -k 'b' *.btr -k 'b' *.BX -k 'b' *.bx -k 'b' *.BZ2 -k 'b' *.bz2 -k 'b' *.CAB -k 'b' *.cab -k 'b' *.CAT -k 'b' *.cat -k 'b' *.CBD -k 'b' *.cbd -k 'b' *.CBK -k 'b' *.cbk -k 'b' *.CDR -k 'b' *.cdr -k 'b' *.CDX -k 'b' *.cdx -k 'b' *.CGM -k 'b' *.cgm -k 'b' *.CHI -k 'b' *.chi -k 'b' *.CHM -k 'b' *.chm -k 'b' *.CHQ -k 'b' *.chq -k 'b' *.CHS -k 'b' *.chs -k 'b' *.CHT -k 'b' *.cht -k 'b' *.CHW -k 'b' *.chw -k 'b' *.CL_ -k 'b' *.cl_ -k 'b' *.CL4 -k 'b' *.cl4 -k 'b' *.CLASS -k 'b' *.class -k 'b' *.CLB -k 'b' *.clb -k 'b' *.CN_ -k 'b' *.cn_ -k 'b' *.CNV -k 'b' *.cnv -k 'b' *.COM -k 'b' *.com -k 'b' *.CPE -k 'b' *.cpe -k 'b' *.CPF -k 'b' *.cpf -k 'b' *.CPI -k 'b' *.cpi -k 'b' *.CPL -k 'b' *.cpl -k 'b' *.CTM -k 'b' *.ctm -k 'b' *.CTX -k 'b' *.ctx -k 'b' *.CUR -k 'b' *.cur -k 'b' *.CW -k 'b' *.cw -k 'b' *.DA_ -k 'b' *.da_ -k 'b' *.DB1 -k 'b' *.db1 -k 'b' *.DBC -k 'b' *.dbc -k 'b' *.DBF -k 'b' *.dbf -k 'b' *.DBX -k 'b' *.dbx -k 'b' *.DCA -k 'b' *.dca -k 'b' *.DCF -k 'b' *.dcf -k 'b' *.DCR -k 'b' *.dcr -k 'b' *.DCT -k 'b' *.dct -k 'b' *.DCX -k 'b' *.dcx -k 'b' *.DE_ -k 'b' *.de_ -k 'b' *.DEL -k 'b' *.del -k 'b' *.DESKLINK -k 'b' *.desklink -k 'b' *.DF_ -k 'b' *.df_ -k 'b' *.DFT -k 'b' *.dft -k 'b' *.DIB -k 'b' *.dib -k 'b' *.DIL -k 'b' *.dil -k 'b' *.DIR -k 'b' *.dir -k 'b' *.DL_ -k 'b' *.dl_ -k 'b' *.DLG -k 'b' *.dlg -k 'b' *.DLL -k 'b' *.dll -k 'b' *.DLS -k 'b' *.dls -k 'b' *.DOC -k 'b' *.doc -k 'b' *.DOT -k 'b' *.dot -k 'b' *.DOX -k 'b' *.dox -k 'b' *.DR_ -k 'b' *.dr_ -k 'b' *.DRV -k 'b' *.drv -k 'b' *.DS -k 'b' *.ds -k 'b' *.DS_ -k 'b' *.ds_ -k 'b' *.DSK -k 'b' *.dsk -k 'b' *.DST -k 'b' *.dst -k 'b' *.DSX -k 'b' *.dsx -k 'b' *.DSZ -k 'b' *.dsz -k 'b' *.DTQ -k 'b' *.dtq -k 'b' *.DWR -k 'b' *.dwr -k 'b' *.EBX -k 'b' *.ebx -k 'b' *.ECW -k 'b' *.ecw -k 'b' *.ELM -k 'b' *.elm -k 'b' *.EMF -k 'b' *.emf -k 'b' *.EN_ -k 'b' *.en_ -k 'b' *.ENU -k 'b' *.enu -k 'b' *.ENV -k 'b' *.env -k 'b' *.EPS -k 'b' *.eps -k 'b' *.ERO -k 'b' *.ero -k 'b' *.ES_ -k 'b' *.es_ -k 'b' *.EWL -k 'b' *.ewl -k 'b' *.EX_ -k 'b' *.ex_ -k 'b' *.EXD -k 'b' *.exd -k 'b' *.EXE -k 'b' *.exe -k 'b' *.EXP -k 'b' *.exp -k 'b' *.FAE -k 'b' *.fae -k 'b' *.FAV -k 'b' *.fav -k 'b' *.FCS -k 'b' *.fcs -k 'b' *.FIL -k 'b' *.fil -k 'b' *.FLL -k 'b' *.fll -k 'b' *.FLT -k 'b' *.flt -k 'b' *.FNT -k 'b' *.fnt -k 'b' *.FON -k 'b' *.fon -k 'b' *.FPT -k 'b' *.fpt -k 'b' *.FPX -k 'b' *.fpx -k 'b' *.FR_ -k 'b' *.fr_ -k 'b' *.FRT -k 'b' *.frt -k 'b' *.FRX -k 'b' *.frx -k 'b' *.FTG -k 'b' *.ftg -k 'b' *.FTS -k 'b' *.fts -k 'b' *.GID -k 'b' *.gid -k 'b' *.GIF -k 'b' *.gif -k 'b' *.GPD -k 'b' *.gpd -k 'b' *.GPT -k 'b' *.gpt -k 'b' *.GRA -k 'b' *.gra -k 'b' *.GRF -k 'b' *.grf -k 'b' *.GZ -k 'b' *.gz -k 'b' *.HDR -k 'b' *.hdr -k 'b' *.HL_ -k 'b' *.hl_ -k 'b' *.HLP -k 'b' *.hlp -k 'b' *.HLX -k 'b' *.hlx -k 'b' *.HT -k 'b' *.ht -k 'b' *.ICM -k 'b' *.icm -k 'b' *.ICO -k 'b' *.ico -k 'b' *.ID -k 'b' *.id -k 'b' *.IDB -k 'b' *.idb -k 'b' *.IDF -k 'b' *.idf -k 'b' *.ILG -k 'b' *.ilg -k 'b' *.ILK -k 'b' *.ilk -k 'b' *.IN_ -k 'b' *.in_ -k 'b' *.IND -k 'b' *.ind -k 'b' *.INS -k 'b' *.ins -k 'b' *.INX -k 'b'
Re: cvswrappers - any better suggestions ?
On Thu, Mar 29, 2001 at 09:26:06AM -0800, Gianni Mariani wrote: SO - I created the following cvswrappers file (all ~700 extensions) that are most likely binary. I got it by scanning my Win drives for all extensions, running 'file' on them and removing any extensions which 'file' reported as 'text'. I've seen extensions that are sometimes binary, sometimes text (eg. MS uses it for some specific binary format, but some freeware packages use it for text). Can't remember offhand what they were; maybe *.inf? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
I've had a number of suggestions below to do a more complete coverage of cvswrappers. Thanks to all who have responded, I have attached my cvswrappers file - consider it public domain. *STANDARD DISCLAIMER* ... I take no responsibility yadda yadda, it IS YOUR FAULT if it breaks your files, melts your computer, wastes your time or money and does unpleasant things yadda yadda and it probably will yadda.*/STANDARD DISCLAIMER* As to Rob's question below, the answer is 'I have no idea and I don't want to think about it - too much'. So I figure it's best to spend 20 minutes making an all encompasing cvswrappers file and if someone forgets to remember to do a "cvs add -kb" then I might just have saved myself 20 minutes of fussing. Turns out that I have already run into this problem - even in a *nix environment with someone checking in a tgz file and it getting munged, and then later in another company when they checked in a bunch o MSVS projects and WAV, BMP and a bunch o files, I just don't remember the extension of, which broke. So this time it's a pre-emptive strike - although I will still be bitten - I know I will, it will probably less frequently. I would actually call this a major deficiency in CVS - it should probably assume binary by default, or even use the command 'file' to detect the file type on adding a file. Destroying files by default is just not recomended 10 out of 10 times - just at a guess. I rant ... Good evening - sweet dreams G -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rob Helmer Sent: Thursday, March 29, 2001 10:03 AM To: Gianni Mariani Cc: [EMAIL PROTECTED] Subject: Re: cvswrappers - any better suggestions ? Hello, Well, I won't ask why you want ot check any of this stuff into CVS ;) You can just do this : *.[Dd][Oo][Cc] to cover all possible capitalizations of .doc files, for instance. HTH, Rob Helmer cvswrappers
RE: cvswrappers - any better suggestions ?
[ On Thursday, March 29, 2001 at 22:21:29 (-0800), Gianni Mariani wrote: ] Subject: RE: cvswrappers - any better suggestions ? I would actually call this a major deficiency in CVS - it should probably assume binary by default, or even use the command 'file' to detect the file type on adding a file. Destroying files by default is just not recomended 10 out of 10 times - just at a guess. WHOA! Hold on just a moment here! "CVS" is the "Concurrent Versions System". It was explicitly and knowingly designed to handle *concurrent* editing of *source* code (i.e. the stuff that's logically mergable with diff3)! Versions of binaries files are, by definition, not possible to merge in any logical way with diff3, ergo CVS does not deal with binary file formats. This cvswrappers crap was a poorly thought out add-on that does not do very much good for anyone and which tries its damndest to go against the core design of CVS from the inside out. If you use it without fully understanding the implications then you only get what you deserve. If CVS destroys binary files by default then that's OK because storing binary files in CVS in the first place is a user error -- it's not designed to handle them in any complete way whatsoever. RTFM. If you want some kind of file and versioning management tool that has some of the characteristics and features of CVS (eg. the user interface, and/or the remote access protocol) then write such a tool -- just don't call it CVS. -- 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
