>>>>> "Christian" == Christian Andersson <[EMAIL PROTECTED]> writes:
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?) Christian> (we have started to intruduce our own version Christian> functionallity in the code so that we can ask what Christian> version of the class we are running, and thisin all the Christian> classes we create ourselves, if we are extending a Christian> class, we first make our own abstract class of this Christian> class that implements the Version interface, all Christian> classes then extends this new class and thus have to Christian> implement the version interface) It's sick that everybody managing a *real* software project have to reinvent this. If only Sun's Java team understood the importance of version tracking in JAR files and in RMI definitions. I was so disappointed that RMI wasn't even an improvement over the 10+year old RPC. It lacking the version checking stuff that RPC has. 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 it was designed primarily for handling program source codes. So, it makes a basic assumption that these codes are *ASCII* text files. (Well... Try a UTF-16 file, and that won't be anything better than binary files to CVS/RCS. UTF-8 and ISO-8859-1 would do better, as these are highly ASCII-compatible.) Many optimizations (such as storing only diffs between versions) are based on this assumption. It's great that CVS does not _require_ this assumption to be met. When the assumption is not met, then it degrades (gracefully), but still works (instead of crashing or becoming crazy). Many "commerical quality" software nowadays on the PeeCee market can't even meet such tolerance! But that doesn't mean it's a good idea to use CVS for binary files. Christian> Well since I come from a windows enviroment, cvs is Christian> mainly used as a version control system, diff/merge is Christian> not used that much by us (yet) and we use cvs because Christian> was the most cost-effective we could find.. Most CVS users will disagree with you. For me, the main reason for using CVS/RCS is to be able to diff/merge between versions. If these operations are not needed, I'd simply store different versions under different file/directory names, so that I can access any version much more directly (no need to checkout/update first). Christian> well i have not been looking at the comand line tool so Christian> much yet and scripts..... Uhhhm... :-) I'm sitting on Christian> a windows machine, and unless I find and install a Christian> shell that is good for this, scripting in DOS is not Christian> that good :-) Windows/DOS gives you a very very very confined view of the giant world. -- 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