You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ben Reser <be...@reser.org> on 2004/07/14 19:43:48 UTC
Subversion 1.1.0 Release Candidate 1 released.
The first release candidate of Subversion 1.1.0 is ready and available from:
http://subversion.tigris.org/tarballs/subversion-1.1.0-rc1.tar.gz
http://subversion.tigris.org/tarballs/subversion-1.1.0-rc1.tar.bz2
The MD5 checksums are:
2a72240c90ab33e0e878d2afa6350110 subversion-1.1.0-rc1.tar.gz
ee3c29e8794fa70206680e0511fa04da subversion-1.1.0-rc1.tar.bz2
PGP Signatures are available at:
http://subversion.tigris.org/tarballs/subversion-1.1.0-rc1.tar.gz.asc
http://subversion.tigris.org/tarballs/subversion-1.1.0-rc1.tar.bz2.asc
PGP Signatures will be made by the following person(s) for this release:
Ben Reser [1024D/641E358B] with fingerprint:
42F5 91FD E577 F545 FB40 8F6B 7241 856B 641E 358B
We encourage all users to test this version to help us discover any last-
minute problems before the 1.1.0 release, although we have a great deal of
confidence that there are no significant bugs. If there are no issues found
1.1.0 will be officially released in about a month.
The changes between 1.0.6 (which also will be released today) and 1.1.0 are
listed below. New 1.1 features are explained in detail in our release notes,
located at:
http://subversion.tigris.org/svn_1.1_releasenotes.html
Questions, comments, and bug reports to users_at_subversion.tigris.org.
Thanks,
-The Subversion Team
--------------------8-<-------cut-here---------8-<-----------------------
User-visible-changes:
* new non-database repository back-end (libsvn_fs_fs)
* symlinks can now be placed under version control (unix systems only)
* fixed: working copies now shareable by multiple users (issue #1509)
* fixed: diff and other subcommands correctly follow renames (issue #1093)
- new 'peg' syntax for diff/merge: 'svn diff -r X:Y TARGET@REV'
* new framework for localized error/info/help messages, initial translations:
- German, Spanish, Polish, Swedish, Norwegian Bokmål
* speed improvements:
- faster 'svn up' on complex working copies -- no more repos txns (r8840)
- faster 'svn status' -- fewer stat() calls (r9182)
- faster 'svn checkout' -- fewer sleep() calls (r9123)
- faster 'svn blame' -- new RA->get_file_revs() func (issue #1715)
* new switches added:
- 'svn blame --verbose' - show extra annotation info
- 'svn export --native-eol TYPE' - export using TYPE line-endings
- 'svn add --force' - recurse into version-controlled dirs
- 'svnadmin dump --deltas' - include binary diffs in dumpfile
- 'svnadmin create --fs-type fsfs' - create fs_fs repos (default is bdb)
- 'svnserve --tunnel-user=NAME' - assume authenticated NAME over tunnel
- 'svndumpfilter [cmd] --quiet' - less chatty dumpfiltering
- 'svnserve --version' - show program's version
'svnversion --version'
'svndumpfilter --version'
* svnadmin dump/deltify now understand -r{DATE} (r9805)
* allow update of non-existent target entry (partial issue #1902 fix)
* 'svnadmin create' now sets sgid bit on repos/db/ (unix systems only)
* increase default neon (ra_dav) timeout from 120 to 3600 seconds (r9568)
* fixed: don't bail when 'svn up' refuses to delete local mods (issue #1806)
* fixed: process svn:externals in defined order (issue #1788)
* fixed: pass new propval to stdin of pre-revprop-change hook (issue #952)
* fixed: svndumpfilter logic/memory/display bugs (r8691, 8831, 9061)
* fixed: 'svnadmin hotcopy PATH .' (r8659)
* fixed: copy crash bug (r8863)
* fixed: allow cleanup on .svn/ dirs containing KILLME file (r8891)
* fixed: 'svn revert' detects corrupted text-base (r8897)
* fixed: 'svn status -N' no longer locks entire tree (r8906)
* fixed: several different 'svn switch' bugs (r9192, 9203, 9238, 9698)
* fixed: some 'svn copy' bugs (r9193, 9274)
* fixed: obscure update-deletion bug (r8976)
* fixed: utf8 conversion 'hang' (r9233)
* fixed: 'svn blame' now defaults to rev (r9440)
* fixed: 'svn diff' shows truncated paths (r9693)
* fixed: 'svn diff --notice-ancestry' bug (r9699)
* fixed: 'svn subcommand -r{DATE} URL' works if URL not in HEAD (issue #1840)
* fixed: 'svn blame' on non-ascii path truncation (issue #1770)
* fixed: svn:external 'wc not locked' bug (issue #1897)
* fixed: proper mod_dav_svn html/xml escaping (issue #1209)
* fixed: memleak in 'svn propset -R URL' (issue #1928)
* fixed: stop 'svn up' from deleting schedule-add target dir (issue #1793)
* fixed: 'svn merge' adding a directory already 'deleted' (issue #1769)
* fixed: excessive memory use when fs deltifies revision 2^N (r10070)
* fixed: disallow non-recursive directory commit (issue #1797)
* fixed: allow propget of props with colon in name (issue #1807)
* fixed: 'svnadmin load' computation of copyfrom-rev (issue #1795)
* general improvement and normalization of error messages
* many improvements to contributed tools: mailer.py, psvn.el, etc.
Developer-visible changes:
* libsvn_fs now loads either bdb (libsvn_fs_base) or fsfs (libsvn_fs_fs)
* new console-printing API: svn_cmdline_printf() family checks for errors.
* new library-version querying API:
- new svn_[libname]_version() in each library
- svn_ver_*() family of functions
* 2nd generation APIs, from svn_foo() --> svn_foo2(). old APIs deprecated.
- svn_wc_adm_open2() & friends, svn_wc_export2(), svn_client_add2()
svn_wc_parse_externals_description2(), svn_hash_read/write2(),
svn_repos_dump/load_fs2() & friends, svn_wc_diff2(),
svn_subst_copy_and_translate2()
* other new APIs:
- svn_stream_copy(), svn_txdelta_target_push(), svn_opt_parse_path(),
svn_io_file_flush_to_disk, svn_repos_trace_node_locations(),
svn_repos_get_file_revs(), RA->get_locations(), RA->get_file_revs,
RA->get_version()
* SVN_REVNUM_FMT_T usage replaced with %ld (r9691)
* neon 0.24.7 now required (fixes wire compression bugs) (r10159)
* cache mod_authz_svn authz file per connection (r8867)
* validate hex digits in % escape (issue #1947)
* hashes now written to disk in sorted order (r9910)
* do cancellation checks before loops, not after (r8918)
* fixed: bug in svn_repos_dir_delta replacement logic (r8078)
* fixed: tiny memory access bugs (r8229, 8230, 8313)
* fixed: several commit buglets (r8955, 9658, 9757, 9855)
* fixed: don't recursively lock all prop commands (r9172)
* fixed: svnserve memory usage on many-file commits (r9185)
* fixed: close svnserve child's listen-socket after forking (r10050)
* fixed: 'svnadmin hotcopy' integrity improvements (issues #1817, #1818)
* fixed: only verify media type of svn:mime-type, not encoding (r10126)
* fixed: handle '//' and '..' in svn_path_canonicalize (issue #1779)
* fixed: double URI escaping (issue #1814)
* huge improvements to python, perl, java bindings
* huge changes to win32 build system
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by Ben Reser <be...@reser.org>.
On Fri, Jul 16, 2004 at 11:18:22AM +0100, Andy Whitcroft wrote:
> It seems that the README.txt within a repository is still BDB specific. I
> thought that there was a commit to fix this, by making it neutral, perhaps
> that missed the branch? I think this is going to be pretty confusing and
> is worth fixing before release. Below is a patch to the README.txt (not
> necessarily that useful) containing a possible rewording.
Before things get updated on the branch someone has to nominate and then
3 people have to vote for it. Nobody has nominated it.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by Ben Reser <be...@reser.org>.
On Fri, Jul 16, 2004 at 11:18:22AM +0100, Andy Whitcroft wrote:
> It seems that the README.txt within a repository is still BDB specific. I
> thought that there was a commit to fix this, by making it neutral, perhaps
> that missed the branch? I think this is going to be pretty confusing and
> is worth fixing before release. Below is a patch to the README.txt (not
> necessarily that useful) containing a possible rewording.
Before things get updated on the branch someone has to nominate and then
3 people have to vote for it. Nobody has nominated it.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by kf...@collab.net.
Andy Whitcroft <ap...@shadowen.org> writes:
> It seems that the README.txt within a repository is still BDB specific. I
> thought that there was a commit to fix this, by making it neutral, perhaps
> that missed the branch? I think this is going to be pretty confusing and
> is worth fixing before release. Below is a patch to the README.txt (not
> necessarily that useful) containing a possible rewording.
Thanks. This was fixed in r10296.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by kf...@collab.net.
Andy Whitcroft <ap...@shadowen.org> writes:
> It seems that the README.txt within a repository is still BDB specific. I
> thought that there was a commit to fix this, by making it neutral, perhaps
> that missed the branch? I think this is going to be pretty confusing and
> is worth fixing before release. Below is a patch to the README.txt (not
> necessarily that useful) containing a possible rewording.
Thanks. This was fixed in r10296.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by Andy Whitcroft <ap...@shadowen.org>.
It seems that the README.txt within a repository is still BDB specific. I
thought that there was a commit to fix this, by making it neutral, perhaps
that missed the branch? I think this is going to be pretty confusing and
is worth fixing before release. Below is a patch to the README.txt (not
necessarily that useful) containing a possible rewording.
-apw
--- README.txt Fri Jul 16 11:09:12 2004
+++ README.new Fri Jul 16 11:15:42 2004
@@ -2,8 +2,12 @@
it. Do not add, delete, or modify files here unless you know how
to avoid corrupting the repository.
-The directory "db" contains a Berkeley DB environment.
-You may need to tweak the values in "db/DB_CONFIG" to match the
-requirements of your site.
+The directory "db" contains the internal representation of the
+repository. The file db/fs-type indicates which internal form
+is in use.
+
+For a Berkeley DB environment (fs-type contains bdb) You may need to
+tweak the values in "db/DB_CONFIG" to match the requirements of your
+site.
Visit http://subversion.tigris.org/ for more information.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
bdb license questions (was: Re: Subversion 1.1.0 Release Candidate
1 released.)
Posted by Peter Koellner <pe...@asgalon.net>.
On Thu, 15 Jul 2004, Ulrich Eckhardt wrote:
> What does 'having a closed source project' have to do with 'needing a newer
> BDB'? And what does all that have to do with Subversion?
considering all this "intellectual property" madness that is happening
today, it is very important to make clear to possible users that no hidden
restrictions have to be feared, or people will not accept your work any
more.
when i have to install a new piece of hardware on a pc of a client company
and i have to open some cd envelope with a seal saying that "by opening the
seal i agree to the software license agreement of the enclosed software",
what am i supposed to do? ask someone if i am allowed to open that?
basically, i do not agree. never.
the company that bought that piece of hardware has no interest at all
in the way the manufacturer makes the devices services available to the
target pc, so there really is no second contract that has to be agreed on,
because the commercial transaction has already taken place and the device
has been paid for. if the manufacturer claims to have any rights after
receiving payment, only because a piece of code they produced exactly for
that purpose is needed to make it work, my natural reaction would be to
laugh in their face.
so naturally, i do not break the seal, but cut open the side of the envelope
to fetch the installation medium. and i NEVER read license agreements i am
forced to agree to when starting the setup program, a long time after money
was transferred. when i have paid for something, i have the natural right
to use it, regardless of any silly laws that might exist somewhere, so i
regard this "yes or no"-questioning as completely void and ignore the whole
thing. but i am fully aware what software manufacturers are trying to do to
me by bombarding me with those silly license agreement forms.
of course, things might be different for companies that want to defend
themselves from legal prosecution gambits by their competition or parasitic
software providers that wait until usage is settled before they begin their
harvest.
also, remember the GIF89a desaster, the rambus patents, and, if you happen
to live in germany, the "explorer" brand name legal exploit by von
Gravenreuth.
so: if the license model is not clear, managers will not like to switch
over from CVS. and that means that a few years have to pass by until the
next generation of computer science students got used to it at the
university. if universities are not starting to get frightened of
intellectual property enslavement too in the meantime...
--
peter koellner <pe...@asgalon.net>
phone: +49 30 44035450 mobile: +49 172 3292977
icq# 161891755 RL: pptp://berlin.de:10437/hiddenseer_str/11
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
Robert Koberg wrote:
> Are there any problems with regard to licensing and Berkeley DB (the
> projects I want to put under subversion are not open source)?
You want to put a closed source project into a Subversion repository? That's
fine. Well, I'm pretty confident it is, because Subversion is in Debian and
the Debian folks pay a lot of attention that there are no restrictions on how
you use the included software.
> If you have a closed source project and need to download a newer version
> of BDB to your server, do you need to pay Berkeley Systems licensing fees?
What does 'having a closed source project' have to do with 'needing a newer
BDB'? And what does all that have to do with Subversion?
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-07-14 at 16:51, Robert Koberg wrote:
> If you have a closed source project and need to download a newer version
> of BDB to your server, do you need to pay Berkeley Systems licensing fees?
Yes, that's my understanding. If you create a closed-source product and
sell it, and it depends on BDB, then you must pay licensing fees to
Sleepycat. For example, Collabnet's own product must do this. If your
project is open-source, then there are no fees.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
Are there any problems with regard to licensing and Berkeley DB (the
projects I want to put under subversion are not open source)?
I remember having some confusion over Berkeley XMLDB and their defintion
of 'deploy.' It turned out that if I developed locally and downloaded
XMLDB from Berkeley Systems to the remote (rackspace) server for a fresh
install and set it up there, it was still considered 'deployed' and
subject to their licensing requirements (which would have been about
US$50k). I don't want to seem like I am slamming Berkeley Systems, just
want to clearly understand the licensing terms as they relate to
Subversion. I had thought a filesystem version would be free of these
worries.
If you have a closed source project and need to download a newer version
of BDB to your server, do you need to pay Berkeley Systems licensing fees?
thanks,
-Rob
Jani Averbach wrote:
>On 2004-07-14 16:09-0500, Robert Guthrie wrote:
>
>
>>Am I correct in assuming that there will be an option to compile an
>>svnserver without the need for a Berkeley DB installation?
>>
>>
>
>Yes, you should compile your apr-util without Berkeley DB support, and
>after that compile subversion against that apr-util. You won't need
>any special option for subversion's configure, because it will find
>from apr-util if there is a bdb or not. During configuration, you
>should get following warning:
>
>configure: WARNING: we have configured without BDB filesystem support
>
>
>The Subversion default filesystem back-end library requires Berkeley
>DB version 4.0.14 or newer, which you don't seem to have
>installed and linked to APR-UTIL. We have created Makefiles which
>will build without the default filesystem library; you will have to
>use "svnadmin create --fs-type=fsfs PATH" to create a repository using
>the alternative FSFS back-end. You can find the latest version of
>Berkeley DB here:
> http://www.sleepycat.com/download/index.shtml
>
>As result, you should now have fsfs only subversion installation.
>
>Br, Jani
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2004-07-14 16:09-0500, Robert Guthrie wrote:
> Am I correct in assuming that there will be an option to compile an
> svnserver without the need for a Berkeley DB installation?
Yes, you should compile your apr-util without Berkeley DB support, and
after that compile subversion against that apr-util. You won't need
any special option for subversion's configure, because it will find
from apr-util if there is a bdb or not. During configuration, you
should get following warning:
configure: WARNING: we have configured without BDB filesystem support
The Subversion default filesystem back-end library requires Berkeley
DB version 4.0.14 or newer, which you don't seem to have
installed and linked to APR-UTIL. We have created Makefiles which
will build without the default filesystem library; you will have to
use "svnadmin create --fs-type=fsfs PATH" to create a repository using
the alternative FSFS back-end. You can find the latest version of
Berkeley DB here:
http://www.sleepycat.com/download/index.shtml
As result, you should now have fsfs only subversion installation.
Br, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by Robert Guthrie <rg...@pobox.com>.
Sorry for my terrible grammar/proofreading. Here's the interpretation
of what I was trying to ask...
Am I correct in assuming that there will be an option to compile an
svnserver without the need for a Berkeley DB installation?
Any hints as to what configure options I'd need to use to make a non-db
svnserver?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release Candidate 1 released.
Posted by Robert Guthrie <rg...@pobox.com>.
Am I correct in assuming that since there's an option to create a
non-database backend server, without needed Berkeley DB? That would
really help me out, where I can't seem to get it to compile, even with
BDB installed.
Any hints as to what configure options I'd need to use to make a non-db
svnserver?
Ben Reser wrote:
> The first release candidate of Subversion 1.1.0 is ready and available from:
>
> http://subversion.tigris.org/tarballs/subversion-1.1.0-rc1.tar.gz
> http://subversion.tigris.org/tarballs/subversion-1.1.0-rc1.tar.bz2
>
> The MD5 checksums are:
>
> 2a72240c90ab33e0e878d2afa6350110 subversion-1.1.0-rc1.tar.gz
> ee3c29e8794fa70206680e0511fa04da subversion-1.1.0-rc1.tar.bz2
>
> PGP Signatures are available at:
> http://subversion.tigris.org/tarballs/subversion-1.1.0-rc1.tar.gz.asc
> http://subversion.tigris.org/tarballs/subversion-1.1.0-rc1.tar.bz2.asc
>
> PGP Signatures will be made by the following person(s) for this release:
> Ben Reser [1024D/641E358B] with fingerprint:
> 42F5 91FD E577 F545 FB40 8F6B 7241 856B 641E 358B
>
> We encourage all users to test this version to help us discover any last-
> minute problems before the 1.1.0 release, although we have a great deal of
> confidence that there are no significant bugs. If there are no issues found
> 1.1.0 will be officially released in about a month.
>
> The changes between 1.0.6 (which also will be released today) and 1.1.0 are
> listed below. New 1.1 features are explained in detail in our release notes,
> located at:
>
> http://subversion.tigris.org/svn_1.1_releasenotes.html
>
> Questions, comments, and bug reports to users_at_subversion.tigris.org.
>
> Thanks,
> -The Subversion Team
>
> --------------------8-<-------cut-here---------8-<-----------------------
>
> User-visible-changes:
> * new non-database repository back-end (libsvn_fs_fs)
> * symlinks can now be placed under version control (unix systems only)
> * fixed: working copies now shareable by multiple users (issue #1509)
> * fixed: diff and other subcommands correctly follow renames (issue #1093)
> - new 'peg' syntax for diff/merge: 'svn diff -r X:Y TARGET@REV'
> * new framework for localized error/info/help messages, initial translations:
> - German, Spanish, Polish, Swedish, Norwegian Bokmål
> * speed improvements:
> - faster 'svn up' on complex working copies -- no more repos txns (r8840)
> - faster 'svn status' -- fewer stat() calls (r9182)
> - faster 'svn checkout' -- fewer sleep() calls (r9123)
> - faster 'svn blame' -- new RA->get_file_revs() func (issue #1715)
> * new switches added:
> - 'svn blame --verbose' - show extra annotation info
> - 'svn export --native-eol TYPE' - export using TYPE line-endings
> - 'svn add --force' - recurse into version-controlled dirs
> - 'svnadmin dump --deltas' - include binary diffs in dumpfile
> - 'svnadmin create --fs-type fsfs' - create fs_fs repos (default is bdb)
> - 'svnserve --tunnel-user=NAME' - assume authenticated NAME over tunnel
> - 'svndumpfilter [cmd] --quiet' - less chatty dumpfiltering
> - 'svnserve --version' - show program's version
> 'svnversion --version'
> 'svndumpfilter --version'
> * svnadmin dump/deltify now understand -r{DATE} (r9805)
> * allow update of non-existent target entry (partial issue #1902 fix)
> * 'svnadmin create' now sets sgid bit on repos/db/ (unix systems only)
> * increase default neon (ra_dav) timeout from 120 to 3600 seconds (r9568)
> * fixed: don't bail when 'svn up' refuses to delete local mods (issue #1806)
> * fixed: process svn:externals in defined order (issue #1788)
> * fixed: pass new propval to stdin of pre-revprop-change hook (issue #952)
> * fixed: svndumpfilter logic/memory/display bugs (r8691, 8831, 9061)
> * fixed: 'svnadmin hotcopy PATH .' (r8659)
> * fixed: copy crash bug (r8863)
> * fixed: allow cleanup on .svn/ dirs containing KILLME file (r8891)
> * fixed: 'svn revert' detects corrupted text-base (r8897)
> * fixed: 'svn status -N' no longer locks entire tree (r8906)
> * fixed: several different 'svn switch' bugs (r9192, 9203, 9238, 9698)
> * fixed: some 'svn copy' bugs (r9193, 9274)
> * fixed: obscure update-deletion bug (r8976)
> * fixed: utf8 conversion 'hang' (r9233)
> * fixed: 'svn blame' now defaults to rev (r9440)
> * fixed: 'svn diff' shows truncated paths (r9693)
> * fixed: 'svn diff --notice-ancestry' bug (r9699)
> * fixed: 'svn subcommand -r{DATE} URL' works if URL not in HEAD (issue #1840)
> * fixed: 'svn blame' on non-ascii path truncation (issue #1770)
> * fixed: svn:external 'wc not locked' bug (issue #1897)
> * fixed: proper mod_dav_svn html/xml escaping (issue #1209)
> * fixed: memleak in 'svn propset -R URL' (issue #1928)
> * fixed: stop 'svn up' from deleting schedule-add target dir (issue #1793)
> * fixed: 'svn merge' adding a directory already 'deleted' (issue #1769)
> * fixed: excessive memory use when fs deltifies revision 2^N (r10070)
> * fixed: disallow non-recursive directory commit (issue #1797)
> * fixed: allow propget of props with colon in name (issue #1807)
> * fixed: 'svnadmin load' computation of copyfrom-rev (issue #1795)
> * general improvement and normalization of error messages
> * many improvements to contributed tools: mailer.py, psvn.el, etc.
>
> Developer-visible changes:
> * libsvn_fs now loads either bdb (libsvn_fs_base) or fsfs (libsvn_fs_fs)
> * new console-printing API: svn_cmdline_printf() family checks for errors.
> * new library-version querying API:
> - new svn_[libname]_version() in each library
> - svn_ver_*() family of functions
> * 2nd generation APIs, from svn_foo() --> svn_foo2(). old APIs deprecated.
> - svn_wc_adm_open2() & friends, svn_wc_export2(), svn_client_add2()
> svn_wc_parse_externals_description2(), svn_hash_read/write2(),
> svn_repos_dump/load_fs2() & friends, svn_wc_diff2(),
> svn_subst_copy_and_translate2()
> * other new APIs:
> - svn_stream_copy(), svn_txdelta_target_push(), svn_opt_parse_path(),
> svn_io_file_flush_to_disk, svn_repos_trace_node_locations(),
> svn_repos_get_file_revs(), RA->get_locations(), RA->get_file_revs,
> RA->get_version()
> * SVN_REVNUM_FMT_T usage replaced with %ld (r9691)
> * neon 0.24.7 now required (fixes wire compression bugs) (r10159)
> * cache mod_authz_svn authz file per connection (r8867)
> * validate hex digits in % escape (issue #1947)
> * hashes now written to disk in sorted order (r9910)
> * do cancellation checks before loops, not after (r8918)
> * fixed: bug in svn_repos_dir_delta replacement logic (r8078)
> * fixed: tiny memory access bugs (r8229, 8230, 8313)
> * fixed: several commit buglets (r8955, 9658, 9757, 9855)
> * fixed: don't recursively lock all prop commands (r9172)
> * fixed: svnserve memory usage on many-file commits (r9185)
> * fixed: close svnserve child's listen-socket after forking (r10050)
> * fixed: 'svnadmin hotcopy' integrity improvements (issues #1817, #1818)
> * fixed: only verify media type of svn:mime-type, not encoding (r10126)
> * fixed: handle '//' and '..' in svn_path_canonicalize (issue #1779)
> * fixed: double URI escaping (issue #1814)
> * huge improvements to python, perl, java bindings
> * huge changes to win32 build system
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release (fsfs as default?)
Posted by Mark Phippard <Ma...@softlanding.com>.
Alan Knowles <al...@akbkhome.com> wrote on 07/14/2004 09:59:06 PM:
> Ben Reser wrote:
>
> >The first release candidate of Subversion 1.1.0 is ready and available
.....
> >
> >
> Congrats - I've been using the fsfs backend for about 3 months? (No
> issues whatsoever.) - Are there any plans to make to the default
> backend, From my watching the mailing list, it would remove 20-30% of
> the posts here.
It wouldn't really make sense to do that in the first release in which it
appears. I think we would want to see it used for a while so that some
knowledge could be built up about any unforeseen problems and recovery
issues as well as performance. Once it has been out there for a while, I
would suspect that it would eventually become the default in a future
release.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.1.0 Release (fsfs as default?)
Posted by Mark Phippard <Ma...@softlanding.com>.
Alan Knowles <al...@akbkhome.com> wrote on 07/14/2004 09:59:06 PM:
> Ben Reser wrote:
>
> >The first release candidate of Subversion 1.1.0 is ready and available
.....
> >
> >
> Congrats - I've been using the fsfs backend for about 3 months? (No
> issues whatsoever.) - Are there any plans to make to the default
> backend, From my watching the mailing list, it would remove 20-30% of
> the posts here.
It wouldn't really make sense to do that in the first release in which it
appears. I think we would want to see it used for a while so that some
knowledge could be built up about any unforeseen problems and recovery
issues as well as performance. Once it has been out there for a while, I
would suspect that it would eventually become the default in a future
release.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release (fsfs as default?)
Posted by Alan Knowles <al...@akbkhome.com>.
Ben Reser wrote:
>The first release candidate of Subversion 1.1.0 is ready and available .....
>
>
Congrats - I've been using the fsfs backend for about 3 months? (No
issues whatsoever.) - Are there any plans to make to the default
backend, From my watching the mailing list, it would remove 20-30% of
the posts here.
Regards
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.1.0 Release (fsfs as default?)
Posted by Alan Knowles <al...@akbkhome.com>.
Ben Reser wrote:
>The first release candidate of Subversion 1.1.0 is ready and available .....
>
>
Congrats - I've been using the fsfs backend for about 3 months? (No
issues whatsoever.) - Are there any plans to make to the default
backend, From my watching the mailing list, it would remove 20-30% of
the posts here.
Regards
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org