The Subversion development team has released version 1.0.3. This is a security bugfix release and the team suggests all Subversion users upgrade: “Subversion versions up to and including 1.0.2 have a buffer overflow in the date parsing code. Both client and server are vulnerable. The server is vulnerable over both httpd/DAV and svnserve (that is, over http://, https://, svn://, svn+ssh:// and other tunneled svn+*:// methods). Additionally, clients with shared working copies, or permissions that allow files in the administrative area of the working copy to be written by other users, are potentially exploitable.”
If I upgrade to Subversion 1.0.3, will TortoiseSVN for 1.0.2 still work with it?
Yes, TSVN 1.0.2 will work fine with 1.0.3.
Subversion will be releasing 1.0.4 soon (probably Friday) and TSVN will be updated when that version is available. I would reccomend upgrading TSVN when they make the new release but, if not, version 1.0.2 should work with any 1.0.X version of Subversion.
Cheers. I’d just converted everyone here at work to Subversion last week, and then this popped up! I figure we’re safe enough behind the firewall though, but it’s nice to know TortoiseSVN isn’t totally tied down.
” wonder why they did not use java for developing Subversion, a quick adavantages list:
– true platform independency.
– fast enough.
– virtually no bufferflow or memory leak problems.
– good libraires. (including servers.)
– a lot of good developers may help to code.
– more managable code.
And since there is a java implementation of sleepy cat, it would be nice to make a java port. too late i guess?”
subversion is a cvs replacement and is meant to be open source. using java wouldnt satisfy that goal. hence no java
Java could have been used as a language but if you read through the mailing lists, it’s apparent that many of the developers are somewhat anti-java. It has nothing to do with subversion being a cvs replacement and being open source. In my opinion, using BerkeleyDB is more problematic in terms of ‘open source’ than using java b/c of the licensing restrictions.
In any event, I don’t mind that it’s not written in java. What I do mind is that there isn’t a full java client api (not talking about a gui) for subversion and the developers insist that it wouldn’t be a good thing to write. They claim it’s too complex and the benefits don’t outweigh the cost. Having a pure java client would make subversion usage skyrocket so it’s unfortunate that they feel this way.
“subversion is a cvs replacement and is meant to be open source. using java wouldnt satisfy that goal. hence no java”
very strance (and meaningless) comment. even apache has tons of open source java apps. java does not prevent usage of java in opensource. what is this ignorance.
———-
And for the previous comment, i see your points thanks for the explanation. my guess is, there were too many linux zealots around when deciding language (i am a supporter of linux too, but thats it). . java suits perfect to the server apps. i see more gain developing the server side in java. but client would be fine too.
“Java could have been used as a language but if you read through the mailing lists, it’s apparent that many of the developers are somewhat anti-java. It has nothing to do with subversion being a cvs replacement and being open source. In my opinion, using BerkeleyDB is more problematic in terms of ‘open source’ than using java b/c of the licensing restrictions”
the db is under bsd license. subversion is under similar apache style license. there is no problem there
“very strance (and meaningless) comment. even apache has tons of open source java apps. java does not prevent usage of java in opensource. what is this ignorance. ”
its no ignorance. java is not open source. cvs is open source. subversion as a cvs replacement and meant to be a open source project will not use non open source components.
“Java could have been used as a language but if you read through the mailing lists, it’s apparent that many of the developers are somewhat anti-java. It has nothing to do with subversion being a cvs replacement and being open source. In my opinion, using BerkeleyDB is more problematic in terms of ‘open source’ than using java b/c of the licensing restrictions”
the db is under bsd license. subversion is under similar apache style license. there is no problem there
“very strance (and meaningless) comment. even apache has tons of open source java apps. java does not prevent usage of java in opensource. what is this ignorance. ”
its no ignorance. java is not open source. cvs is open source. subversion as a cvs replacement and meant to be a open source project. a java base wouldnt mean no linux distribution will ship it and it would definitely hinder adoption of it by open source projects
No, Subversion and Berkeley DB are under completely different licenses (see links below). Berkely DB requires that your product include source code unless you pay for a license to redistribute. Java has no such restriction on redistribution nor does Subversion.
You wrote:
“java is not open source. cvs is open source. subversion as a cvs replacement and meant to be a open source project. a java base wouldnt mean no linux distribution will ship it and it would definitely hinder adoption of it by open source projects ”
You are comparing a ‘platform’ to an application. It’s sort of like saying Windows isn’t open source so subversion should not run on it. There are so many open source products written in Java and there’s no reason why it couldn’t have been used to write Subversion.
I do see your point about java on linux but that’s a separate issue. Any distro could ship with java and at various times have. I doubt that many distro’s will ship Mono even though they can… it’s simply an open source politcal stance that they are taking.
Subversion’s Apache/BSD style license
http://subversion.tigris.org/license-1.html
Sleepcat’s
http://www.sleepycat.com/download/oslicense.html
http://www.sleepycat.com/download/licensinginfo.shtml
“The open source license for Berkeley DB permits you to use the software at no charge under the condition that if you use Berkeley DB in an application you redistribute, the complete source code for your application must be available and freely redistributable under reasonable conditions. If you do not want to release the source code for your application, you may purchase a license from Sleepycat Software.”
ps you may want to look at this:
Berkeley DB Java Edition
http://www.sleepycat.com/products/je.shtml
So what does this do to your open source claims?