Please read this one through before answering :-) (i'm happy this kind of discussion happens, since it allows me to learn)
> > So what you are saying is that if we are several developers spread across > > several places (perheps even different countries) and in our project we use > > 3:rd party jar-files, is that we should have second system for delivering > > these jar-files to the developers and making sure that they are all using > > the same versions? > > "delivering" What can that possibly mean in this context?!?!?! Surely > each site can all keep their own copies of these files -- they don't > change betweeen revisions, by definition! Since cvs is a Version System, (sometimes only a single program, and sometime it is set up as a client server system) it keeps track of different version of files, and what do I have, I have different versions of files, some older ones should be used with together with older versions of other files. If we are packaging a bug-fix for our software for a specific user, we would perheps need to use older versions of some files. What these files contains really really should be no big difference, however when it comes to cvs compared to other version systems, this does matter a bit, since cvs stores not the complete file but the changes in a file (when they are text files and not binary) so binary files are not cost-effective to store in cvs, BUT they can be stored in cvs, if we are not supposed to do so, then why let us? Delivering, well I could use e-mail for sending out different versions of files to the developers, we could also be using ftp, or any other such system,instead of using a system that already does this and are beeing used. ... > 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. That might be a possible sollution, but unlike libraries and dll files it is easy for several versions of a jar file to exist within one machine without them competing with each others, with for example microsoft (urgh) and dll files this is not so, if you try to access a dcom component in that system there is only one version of that component,you cannot (afaik) have 2 versions of the same dcom component registered. Also there is one more difference, Dll components know there version, not all jar-files know theirs and there is not ONE system to ask for this information, like there is with dll files. If the jar-file if has a manifest file, you can specify the version number, however there might be no manifest file, and then we do not know th version of the jar file, and even worse is the fact that unless you write your own classloader, your java program has no say in what jar-files should be used, I cannot in the java program find out that there is 3 different versions of a jar (class) and use the one appropiate, it uses the principle first found first used, patching a program can then be done by just palsing a new jarfile first in the classpath that is used to start the program.) What I can do is making an external script that does this, however since java is designed to exist on several different operating systems we cannot relly on the script to solve this (try scripting in dos, it can be done but it is not easy, and there are limitations that you do not have in for example bash and other such shells) and unfourtunally we as programmers do not have much say in what operating systems the users should use when running our system. > > And why should we have to use 2 different versioning systems for this, I > > agree that using cvs for storing binary files are not "cost effective", but > > using 2 different versioning systems for this is I think even worse. > > 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? Why would you > insist on trying to hammer in machine screws with the handle of a > soldering iron? Not designed to? then my english must not be that good, here I thought cvs stood for concurrent version system, a system that manages to keep track and controle different versions of files. and what was my problem? well i have different versions of files and I need to control/keep track of them.I need to control that the developers are using the newest files to work with, although, this however is not something cvs can do for me, I have to do that manually by checking with the cvs that I have the latest versions of files that I need to work with. Although cvs is not primarly designed to store binary files, it can do that, but remember that cvs was not designed to be a client server system either, but that has now changed, it was also not really designed to have a gui-client, but it has that now also (and these two things is somthing I am very glad for) Unfourtunally due to "design flaws"? in java, this particulary soldering iron, have a handle that has a sharp edgeand fits to the screw, I do not need to hammer at all, and this screw is a bitt different, so other screwdrivers fit as good as this handle.... > > What wuld be nice to have is a developement project system that takes care > > of versioning and many more things, but unfourtunally I have not seen any > > that I like yeat, and that is not to costly. So for now cvs is a > > sollution... > > Software development is done with a collection of tools that you need to > learn to use and integrated to the best of their abilities and to suit > _your_ needs. I agree, but if we can manage with less tools, is not that better? for instance lets say that you have an enviroment where you are working against several databases, then you might have several sql-editors (the mysql program for mysql, sql+ for oracle and a gui program for informix) and several ways to run sql-code (to test it manually for example) would it not be better and more efficient if you could have just one program for this (some sql-programs do just this)? If I have to install/use more systems to be able to work, then it would take more time and in effect cost more to develope programs, and I guess not even you work for free all the time. I admit that CVS is not 100% suited and there might be tools out there that is, but I have not found it yet, to handle it all manually is possible, but it takes up to much time for us developers, making hte programs more expensive.. if cvs can lessen our time doing manually stuff, why not use it.. and cvs can do this. There are other version systems out there that can do this also, but many of them are very expensive, and some cannot be used un such a variety of different operating systems (I am using win2k, an other developer is using linux) The only thing I miss in cvs, is an easier way to handle dependecies, but I do not think cvs was designed for this at all. ofcourse you could tag files so that you manually have controll of this, but here we might have to use a different tool, which I have not found yet. ofcourse we could use tagging, if my understanding of that is correct, but then i think it would be a more manual handling, if you can tell me that I am wrong, I would be pleased. I'm not telling that cvs should be used on the client that the finished product is installed on, only in the developement... :-) I am also not saying that the cvs sollution is the best sollution, but sofar I have not found a better one, that allows us to share7manage/control different versions of the same jar file with a minimum penelty cost (in time and money) > If you want an entirely integrated development environment then might I > suggest you go find one. They do exist, but so far as I know CVS is not > even a component in any of them. When I want such an environment I find > the Squeak implementation of Smalltalk-80 to be very suitable for my > needs. I'm told some of the commercial Smalltalk implementations go > even further down the road of full project managment and do even better > with assisting in the whole process of software configuration management. Well unfourtunally smalltalk is not an option for all to choose, and I'm sure that smalltalk have other differences to java that makes it less usuable.. ( have not used smalltalk myself, only read a little about it). So for us (the company I'm working for now), Java is the system we will use... We could ofcourse go to the .NET plattform, but do i really want that? Nope! :-) (if that happens, I think I'll be out there looking for a new jobb) /Christian Andersson _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
