No, because, sadly, many applications require a specific version of the javaVM. At university we had a vpn solution that only worked with 1.4.3, although 1.5 was already released.
MySQL, as others have pointed out, has better developer support and they know their target audience. They supply a fast, easy to use database for those who don't need a whole lot.
Limewire and Azureus. Both have overly complex hard-to-use GUIs and flaky behavior. (Not redrawing parts of the window correctly, opening windows in strange places and not where you expect, opening dialogs on a different monitor from the main app, etc.)
Fair enough, but why blame on Java, a language portable by design, that don't have not portable features? Use a non portable language. Or learn to program in Java and C. I do.
# Lack of support for UNIX-domain sockets # Lack of support for SysV semaphores # Lack of support for SysV shared memory # Lack of support for UNIX signals (other than SIGTERM) # Lack of any serious UNIX-style job control # Lack of any interface to map files into memory # Lack of any API to make system calls # In fact, the Java implementation suffers from a general lack of support for almost all of the standard UNIX IPC mechanisms, save INET sockets. How lame is that?
You have your facts outdated. Java NIO API allows for memory mapping files for the last 5 years or more. All the UNIX IPC methods are that: UNIX IPC. Not portable IPC, that would allow to make a portable Java implementation. But, hey, you can make your own library to implement it with native (with JNI API) calls. Why everyone wants any single feature of every platform in the Java core is out my comprehension. Perhaps they are mind numbed from too much PHP.
You must be kidding. You just dumped the blame on what USA did -according to previous poster- on tropical countries? BTW, in Amazonas there are countless unknown species, you suggest that when they deforest to plant your cheap ethanol farms they replant exactly what in exactly where?
The way you do rename in cvs don't preserve history. Yes, the file will have a new name from now on, but it breaks any previous version builds. YMMV depending on your language, tools, etc Doesn't work for many use cases, but more importantly, it isn't clear in cvs logs. CVS just doesn't support it.
It seems that cvs admin -o isn't a very "mature" or robust option. On the contrary it is very manual and can be dangerous.
From the manual:
None of the revisions to be deleted may have branches or locks. If any of the revisions to be deleted have symbolic names, and one specifies one of the '::' syntaxes, then CVS will give an error and not delete any revisions. If you really want to delete both the symbolic names and the revisions, first delete the symbolic names with cvs tag -d, then run cvs admin -o. If one specifies the non-'::' syntaxes, then CVS will delete the revisions but leave the symbolic names pointing to nonexistent revisions. This behavior is preserved for compatibility with previous versions of CVS, but because it isn't very useful, in the future it may change to be like the '::' case. Due to the way CVS handles branches rev cannot be specified symbolically if it is a branch. See section 5.5 Magic branch numbers, for an explanation. Make sure that no-one has checked out a copy of the revision you outdate. Strange things will happen if he starts to edit it and tries to check it back in. For this reason, this option is not a good way to take back a bogus commit; commit a new revision undoing the bogus change instead (see section 5.8 Merging differences between any two revisions).
Subversion has an established procedure for doing this, it just doesn't do it on an online repository: svndumpfilter exclude calc calc-dumpfile
Efficiency of storing binaries is very inconsequential when storage is free these days. Not only that, but efficiency of delta'ing varies and wasteful in time (lookup bsdiff) so why bother? And with the obliterate option, it makes the issue moot, and SVN unusable for binary CM and deployments. You seem to have a need to delete old binary files. I don't see the point to do that. You are agreeing that storage is cheap. I think most people would prefer to keep history if not hard pressed by storage limits. If you google it or in comments you'll see some people with multigigabytes and no plans to obliterate any part of it. The SVN procedure is enough for this as a repository maintenance option. Perhaps not the majority of user needs to obliterate regulary.
HTTP may has no use for you, but for other people may be a show stopper. CVS doesn't support alternate protocols. SVN supports SSH with svnserve, so it's more flexible.
I just wish there CVS would maybe uses BerkeleyDB or something faster for the file db in backend so tagging isn't so slow
I think that is a design flaw of CVS. You may want to check http://www.march-hare.com/cvspro/. It support some niceties than CVS has not and in some cases even SVN, though their comparison seem a little outdated. Disclaimer: I haven't tried it:-)
I guess you know what your talking. Let me ask a question: do those website use MySql on financial transactions applications? Your applications are surely important to you and high volume, but what kind of apps and transactions are we talking about? Some people show concerns of using MySql for mission-critical operations, and I'm not including social networking apps in that category. Digg is very interesting technology speaking BTW.
SVK its based on SVN and says history sensitive merging:
svk is a decentralized version control system built with the robust Subversion filesystem. It supports repository mirroring, disconnected operation, history-sensitive merging, and integrates with other version control systems, as well as popular visual merge tools.
Then again, you could simply zip or tar up the binaries and put them on a fileserver. The filenames will be easily identifiable and unique. Subversion (or any other CVS type system) is the wrong tool for the job.
Maybe but then you may want to have a tool to automate adding new versions, then you would want something to automate comparing versions, if you have limited bandwidth it would be useful to send only deltas, specially with big files. To make it short, you end with a Subversion clone. Because Subversion is at its core a versioned filesystem.
Storing JAR files in SVN is wrong most of the time. Either the JAR file is built from the sources in this same repository, and build results should really not be stored in SVN. Or it is required to build the software - then it should be part of the local computer's software installation, and your ~/build.properties should point to the exact location.
For most simple projects its easier to just commit the jars within the project. That way one can just checkout and compile. With your way, where the programmer is supposed to get the jars? and what is the problem with keeping them in the SCM?
Atomic commits would be nice, renames easily done on the repo with recoverable side-effects, why http? otherwise cvsweb, no binary delta is GOOD because binary-patches are SLOW and unnecessary red-herring (CVS has obliterate; what does SVN have?), handled gigs of mission-critical binaries safely so far.
CVS doesn't handle renames, you have to do it manually with add and delete and there is no link from the new file to the old. SVN isn't perfect (rename = copy + delete) but at least supports copy preserving history and it's planed to support true renames. HTTP/HTTPS is good for flexibility if you need to access from internet or your security infrastructure uses client certificates, LDAP authentication or you need to pass over a proxy. Not for everyone but is good to support different use cases. Some people seem to disagree over binary deltas. AFAIK there is not an obliterate command in CVS and neither in SVN. You must carry a manual procedure (dump/filter/restore in SVN case). Many CVS projects are migrating to SVN (GCC, all of Apache, GNOME, KDE, etc). Don't hear any of them going back. In fact CVS is very inefficient storing binary files, it stores the full version in the,v. SVN store deltas, so it can reduce the storage size. But if you are happy with CVS, more the good to you. It served me well, but it looks older each.
Subversion has hooks where it call scripts, like precommit, postcommit, etc. You can implement what you want in those scripts. Some are contributed in subversion site.
Sun just released it it seems. They are asking for community help to replace the proprietary bits. They are doing a lot and doing what they said, you can't deny that.
But ask yourself: can you do space invaders in GWT? It doesn't seem that GWT is an alternative to Flash like JavaFx or Silverlight. It's comparing pears and cats.
You can hide from the right button menu or open the control panel (in same menu) and disable it. It's a bit intrusive but it seems that every windows app want to put an icon there this days.
Slashdot Mirror
It hasn't, mainly because Java 1.4.3 never existed.
Dude, if your wife reads slashdot you may just striped yourself!
What is exactly easier in MySql?
Oh yeah:
java/.Net crashes
Let's not use any Energy that is not GPL'ed!!! Closed sources Energies are the cause of all evil!!!
Seems GP don't like SWT either.
It seems people in Slashdot don't understand how an company works and what a bottleneck can be a legal department sometimes.
This is Slashdot. We do not say "they killed the project". We say "but BSD/OpenSolaris/ZFS/etc is dead".
Versionists?
Or Centralism vs. Distributionism?
the simple answer is: YeNso
Fair enough, but why blame on Java, a language portable by design, that don't have not portable features? Use a non portable language. Or learn to program in Java and C. I do.
You have your facts outdated. Java NIO API allows for memory mapping files for the last 5 years or more. All the UNIX IPC methods are that: UNIX IPC. Not portable IPC, that would allow to make a portable Java implementation.
But, hey, you can make your own library to implement it with native (with JNI API) calls. Why everyone wants any single feature of every platform in the Java core is out my comprehension. Perhaps they are mind numbed from too much PHP.
You must be kidding. You just dumped the blame on what USA did -according to previous poster- on tropical countries?
BTW, in Amazonas there are countless unknown species, you suggest that when they deforest to plant your cheap ethanol farms they replant exactly what in exactly where?
It seems that cvs admin -o isn't a very "mature" or robust option. On the contrary it is very manual and can be dangerous.
From the manual:
Subversion has an established procedure for doing this, it just doesn't do it on an online repository:
svndumpfilter exclude calc calc-dumpfile
Efficiency of storing binaries is very inconsequential when storage is free these days. Not only that, but efficiency of delta'ing varies and wasteful in time (lookup bsdiff) so why bother? And with the obliterate option, it makes the issue moot, and SVN unusable for binary CM and deployments.
You seem to have a need to delete old binary files. I don't see the point to do that. You are agreeing that storage is cheap. I think most people would prefer to keep history if not hard pressed by storage limits. If you google it or in comments you'll see some people with multigigabytes and no plans to obliterate any part of it. The SVN procedure is enough for this as a repository maintenance option. Perhaps not the majority of user needs to obliterate regulary.
HTTP may has no use for you, but for other people may be a show stopper. CVS doesn't support alternate protocols. SVN supports SSH with svnserve, so it's more flexible.
I think that is a design flaw of CVS. You may want to check http://www.march-hare.com/cvspro/. It support some niceties than CVS has not and in some cases even SVN, though their comparison seem a little outdated. Disclaimer: I haven't tried it
I guess you know what your talking. Let me ask a question: do those website use MySql on financial transactions applications? Your applications are surely important to you and high volume, but what kind of apps and transactions are we talking about?
Some people show concerns of using MySql for mission-critical operations, and I'm not including social networking apps in that category. Digg is very interesting technology speaking BTW.
Maybe but then you may want to have a tool to automate adding new versions, then you would want something to automate comparing versions, if you have limited bandwidth it would be useful to send only deltas, specially with big files. To make it short, you end with a Subversion clone. Because Subversion is at its core a versioned filesystem.
For most simple projects its easier to just commit the jars within the project. That way one can just checkout and compile. With your way, where the programmer is supposed to get the jars? and what is the problem with keeping them in the SCM?
CVS doesn't handle renames, you have to do it manually with add and delete and there is no link from the new file to the old. SVN isn't perfect (rename = copy + delete) but at least supports copy preserving history and it's planed to support true renames.
HTTP/HTTPS is good for flexibility if you need to access from internet or your security infrastructure uses client certificates, LDAP authentication or you need to pass over a proxy. Not for everyone but is good to support different use cases.
Some people seem to disagree over binary deltas.
AFAIK there is not an obliterate command in CVS and neither in SVN. You must carry a manual procedure (dump/filter/restore in SVN case).
Many CVS projects are migrating to SVN (GCC, all of Apache, GNOME, KDE, etc). Don't hear any of them going back.
In fact CVS is very inefficient storing binary files, it stores the full version in the
But if you are happy with CVS, more the good to you. It served me well, but it looks older each.
No atomic commits, no renames, no http, no delta of binary files, no safe handling of binary files...
Subversion has hooks where it call scripts, like precommit, postcommit, etc. You can implement what you want in those scripts. Some are contributed in subversion site.
Sun just released it it seems. They are asking for community help to replace the proprietary bits.
They are doing a lot and doing what they said, you can't deny that.
This is one of the needless request I ever seen for Java. What's next, NOP?
But ask yourself: can you do space invaders in GWT? It doesn't seem that GWT is an alternative to Flash like JavaFx or Silverlight. It's comparing pears and cats.
You can hide from the right button menu or open the control panel (in same menu) and disable it. It's a bit intrusive but it seems that every windows app want to put an icon there this days.