>>>>> "Christian" == Christian Andersson <[EMAIL PROTECTED]> writes:
Christian> Since cvs is a Version System, (sometimes only a single Christian> program, and sometime it is set up as a client server Christian> system) it keeps track of different version of files, Christian> and what do I have, I have different versions of files, Christian> some older ones should be used with together with older Christian> versions of other files. I used to use CVS to store 3rd-party jar files during a 1+ year Java development project that I managed. I keep them in a "lib" directory, and use "-kb" to put them into CVS. This way, I can be very sure that every snapshot I've tagged will work the same way as when it was tagged. CVS also lets me write log messages to explain why we upgraded some of the JAR files, and what versions (the 3rd party's version number) they are. Of course, there are some considerations in terms of efficiency. 1) File size. The JAR files that I manged in CVS are quite small in size. They are less than 1MB. 2) Update frequency. Usually, during a certain phase of development, I refrain from upgrading the libraries (so as not to introduce new variations on the environment). Only when the library has got a very very important bug-fix that we deadly need, will I have a library update within a phase. And I would announce it to all developers so that they will retest their code against this. From phrase to phrase (which is months part), I may upgrade to a newer version of the library. Since the file size is not large, and the JAR files under CVS are not changed frequently, I don't think CVS is unsuitable here. At least, the version control part makes life much easier to reproduce any snapshot. Christian> BUT they can be stored in cvs, if we are not supposed Christian> to do so, then why let us? I agree! My advice is: don't over-do it. You know that it is inefficient. So, don't do that too often. >> and used in conjunction with your own software. Since Jar >> files are used dynamically at run time you should use run-time >> configuration parameters to ensure the correct versions are >> found and used by a given version of your software. Christian> That might be a possible sollution, but unlike Christian> libraries and dll files it is easy for several versions Christian> of a jar file to exist within one machine without them Christian> competing with each others, with for example microsoft Christian> (urgh) and dll files this is not so, if you try to Christian> access a dcom component in that system there is only Christian> one version of that component,you cannot (afaik) have 2 Christian> versions of the same dcom component registered. Also Christian> there is one more difference, Dll components know there Christian> version, not all jar-files know theirs and there is not Christian> ONE system to ask for this information, like there is Christian> with dll files. Yeah! These are problematic. Not only JAR, but also RMI do not have version info as a compulsory requirement. (How could Sun have done that with RMI, given that they have RPC to copy from?) >> Why would you try to use one tool which has a _very_ specific >> capability to do something that it is explicitly not designed >> to do? When I see it fit. Period! My credit card is also designed to server a very very specific purpose. But when I can't a ruler nearby and I need one, why not use that plastic object from purse as a ruler? Christian> Not designed to? then my english must not be that good, Christian> here I thought cvs stood for concurrent version system, Christian> a system that manages to keep track and controle Christian> different versions of files. But _mainly_ text files which do not differ a lot from version to version. At least, the implementation makes this assumption and optimizes on it. The support for binary files is just a "refuge" just in case you need to keep binary files. Christian> and what was my problem? Christian> well i have different versions of files and I need to Christian> control/keep track of them. If all your files are 30MB binary files, then CVS won't do you anything better than manually appending a version-id to the name of your file and using a README file for storing the revision log messages. If you can't 'diff' and 'merge', why are you using CVS? ( I did have some discussions with some colleagues from another team who intended to store MSWord .doc files with CVS. My team uses XML -- text files -- and hence CVS works well. I often 'diff' them. But with MSWord .doc files, what are you supposed to do? A 'diff' or 'merge'? Haha... These were the question I raised during the discussions. If you can't even 'diff' or 'merge', then why are you using CVS? What's CVS good for? If all you want is just storing different versions and possibly attaching a description for each version, then store them under systematically different names and describe them with a README file! ) Christian> I need to control that the Christian> developers are using the newest files to work with, Not always newest. Consider a developer working on a bug on an older (but released) version. He may want the older version (at the release time) of all the file instead of the newest. In a nutshell, the *correct version*, not necessarily the newest. Christian> if cvs can lessen our time doing manually stuff, why Christian> not use it.. and cvs can do this. I agree with you here. Given the 2 conditions on your JAR files under CVS, I don't think it is a big problem. If that constitutes less than 5% of all your files controlled under CVS, either by size or by number, then I don't think you'd be better off finding a "saner" way of storing those 3rd-party JAR files. However, when you have so many such JAR files that they take up >30% of your repository, then that's heavy-duty enough to consider a tool that can manage binary files better. It's just a tradeoff in the practical scenario. Of course, purely theoretically, we should never ever use CVS for any bit of binary file. But practically, I find it acceptable for a few infrequently changing, small JAR files from 3rd parties. Christian> There are other Christian> version systems out there that can do this also, but Christian> many of them are very expensive, and some cannot be Christian> used un such a variety of different operating systems Christian> (I am using win2k, an other developer is using linux) And they may not be as flexible and stable as CVS! (The command line CVS tool is very very important! You can write scripts to do many useful things out of it. I would thus avoid those that don't even provide a command line interface.) -- Lee Sau Dan §õ¦u´°(Big5) ~{@nJX6X~}(HZ) E-mail: [EMAIL PROTECTED] Home page: http://www.informatik.uni-freiburg.de/~danlee _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs