You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <be...@reser.org> on 2005/04/07 20:53:29 UTC
Subversion 1.2.0 Release Candidate 1 released.
The first release candidate of Subversion 1.2.0 is ready and available
from:
http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.tar.gz
http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.tar.bz2
http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.zip
The MD5 checksums are:
c96be2d7591b7ee260ac372fe1248dff subversion-1.2.0-rc1.tar.gz
b99e49eea110ebfca338b62db5f5a2be subversion-1.2.0-rc1.tar.bz2
d28d5f6fd84b9f4651e879af0b9500c6 subversion-1.2.0-rc1.zip
The SHA1 checksums are:
75138673c63b8e5015ff2f9ffdc6f27e49f4d65d subversion-1.2.0-rc1.tar.gz
a64ae487bbb3e752e074c59e1f9665fc5e53bd7b subversion-1.2.0-rc1.tar.bz2
e65c81a507a95ad5ad7645c776ab48b841602011 subversion-1.2.0-rc1.zip
PGP Signatures are available at:
http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.tar.gz.asc
http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.tar.bz2.asc
http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.zip.asc
For this release, the following people have provided PGP signatures:
Ben Reser [1024D/641E358B] with fingerprint:
42F5 91FD E577 F545 FB40 8F6B 7241 856B 641E 358B
Ben Collins-Sussman [1024D/EC6B5156] with fingerprint:
9FBF BEB7 409D D55F 6946 5CC6 5348 1A68 EC6B 5156
Daniel J. Berlin [1024D/51E507AC] with fingerprint:
DAD6 3E94 EBF8 A39A A0AF E193 EC59 A047 51E5 07AC
Erik Huelsmann [1024D/96B3F539] with fingerprint:
261D D45F EBBA 0993 2693 3CCB 8B93 B412 96B3 F539
Karl Franz Fogel [1024D/DB00A248] with fingerprint:
B77E 8FB2 112F 9637 2E3E 3F08 BC9D BB13 DB00 A248
Justin R. Erenkrantz [1024D/E2226795] with fingerprint:
3C01 6F2B 7646 21BB 549C 66B5 16A9 6495 E222 6795
Brian W. Fitzpatrick [1024D/F894BE12] with fingerprint:
464F C03E 1D47 A2D0 BB7E F03C FC0F 8589 F894 BE12
The term 'release candidate' means the Subversion developers feel that
this release is stable and ready for production use, so we encourage
people to test this release thoroughly. The final 1.2.0 release is
scheduled for early-May, in order to provide plenty of time for
testing.
Please note that if you run the test suite that there is a failure
reported in copy_tests.py test #25 when running against a DAV server.
This is a known issue with the test not with Subversion itself and will
be fixed in the next release.
The changes between 1.1.4 and 1.2.0-rc1 are listed below.
New 1.2 features are explained in detail in our release notes,
located at:
http://subversion.tigris.org/svn_1.2_releasenotes.html
Questions, comments, and bug reports to users_at_subversion.tigris.org.
Thanks,
-The Subversion Team
--------------------8-<-------cut-here---------8-<-----------------------
User-visible-changes:
- Client:
* add peg-rev syntax to co/blame/cat/ls/pget/plist/export (issue #1093)
* 'svn info' now works on URLs (r13123, 13144)
* new 'svn version' subcommand, essentially same as --version (r10430)
* 'svn* --version' now shows available repository back-ends (r13761)
* new fixed-length keywords (for placement in binary files) (issue #2095)
* on Windows, disk-cached passwords are now encrypted (r13888)
* performance improvements:
- 'svn status' does much less disk parsing (r11677, 11704)
- 'svn st -u' no longer asks server to generate textdeltas (issue #2259)
- 'svn revert -R' doing much less work (r13883)
- utf8<->native conversions are faster now (issue #2016)
* new switches added:
- 'svn log --limit N' - show only first N log messages
- 'svn info --revision' - show info on older object (r13265)
- 'svn list --xml' - output listing in XML
- 'svn propset --force' - allow unusual propsets (#2065)
- 'svn diff --force' - show diffs on binary files (#2099)
- 'svn co/up/st --ignore-externals' - skip over externals (#2189)
- 'svn export --non-recursive' - don't export subdirs (issue #2228)
- 'svnversion --help' - show help (r13128)
* fixed: 'svn merge' fails to add symlinks or expand keywords (issue #2064)
* fixed: 'svn merge --dry-run' shows spurious 'skip' messages (issue #1943)
* fixed: 'svn merge' file-not-found' error (issue #1673)
* fixed: 'svn merge' of propchanges into deleted file (issue #2132)
* fixed: 'svn merge' on implicit target with space (r13010)
* fixed: 'svn switch/update' failure might corrupt wc (issue #1825)
* fixed: 'svn up' should rm before add, helps case-insensitivity (r12616)
* fixed: 'svn up -rX' causes file to be unrestorable (issue #2250)
* fixed: 'svn copy wc wc' should keep .svn/ hidden (issue #1739)
* fixed: 'svn copy wc wc' of deleted=true doesn't delete (issue #2101)
* fixed: 'svn copy' shouldn't copy into schedule-delete area (issue #2020)
* fixed: 'svn log' throws error on unversioned target (issue #1551)
* fixed: 'svn log' in r0 working copy shows r1 log msg (issue #1950)
* fixed: 'svn export' bugs on deleted dirs or nonexistents (#2226, r13226)
* fixed: 'svn export' on single file from working copy (issue #1708)
* fixed: 'svn commit' ignores --encoding when editing externally (#2244)
* fixed: 'svn commit' log message lost if utf8-conversion failure (r13230)
* fixed: 'svn diff' output encoding bug (r11461)
* fixed: 'svn diff' showing prop-diffs on repos root dir (r13381-2)
* fixed: 'svn diff' label reversal (issue #2033)
* fixed: 'svn propset' should skip unversioned files (#2030)
* fixed: 'svn rm URL1 URL2 URL3...' huge memory usage (issue #2218)
* fixed: 'svn mkdir' cleanup after failure (r11883)
* fixed: 'svn status -u' crash in non-recursive wc's (issue #2122)
* fixed: 'svn revert' should skip unversioned items (issues #2030, 2133)
* fixed: 'svn revert' should suggest --recursive (issue #2114)
* fixed: 'svn add/import' better detects invalid paths (issue #1954)
* fixed: 'svn cleanup' should repair timestamps (r12012)
* fixed: fuzzily escape control-characters when sending over dav (#2147)
* fixed: prevent client from manipulating svn:wc:* properties (r12523)
* fixed: xml-escaping bugs over dav (r11090)
* fixed: store symlinks as utf8, always work in non-utf8 locale (r11358-9)
* fixed: bug in special-file detranslation (r11441)
* fixed: show paths in local-style where we weren't (issue #1538)
* fixed: detect invalid propnames better (issue #1832)
* fixed: entire error stack not being printed (issue #1822)
* fixed: improper utf8 conversion of revision strings (issue #1999)
* fixed: use-commit-times timestamp bug (r12906)
* fixed: canonicalize values of svn:keywords prop (issue #2219)
* fixed: don't comment out section-names in default config file (r11771)
* more support for user-cancellation (r13083-4, 13086)
* improved error messages (r12920, 11392, 11599, 11913, #2154, #2214)
- Server:
* mod_dav_svn autoversioning feature now complete (see release notes)
* 'svnadmin create' now creates FSFS repositories by default (r13624)
* new pre/post-revprop hook argument to describe propchange (r12162)
* mod_authz_svn groups can now contain other groups (issue #2085)
* 'svnadmin recover' now creates default svnserve passwd file (r11589)
* increase default BDB cache size in DB_CONFIG (r13030)
* new switches added:
- 'svnlook diff --no-diffs-deleted' - suppress deleted diffs (#2180)
- 'svnadmin load --use-pre-commit-hook'
'svnadmin load --use-post-commit-hook'- invoke hooks when loading
- 'svnlook propget/proplist --revprop' - show revision props (#2181)
* fixed: change FSFS revprops atomically and safely (issue #2193)
* fixed: FSFS should verify checksums (issue #2253)
* fixed: 'svnadmin create' should clean up when it fails (r13200)
* fixed: 'svnadmin load' compatibility on pre-0.14 dumpfiles (r12075)
* fixed: 'svnadmin load' crashes on contentful rev 0 (issue #1674)
* fixed: 'svnadmin dump' should write in console encoding (issue #1997)
* fixed: check for null-streams in dump/load code (r10510)
* fixed: hook script ignored when symlink is broken (issue #1700)
* fixed: hook script may inherit server's stdin stream (r12155)
* fixed: potential svnserve segfault (r13199)
* fixed: svnserve handling mutually-exclusive options (issue #2251)
* fixed: mod_authz_svn should log errors to httpd errorlog (issue #2182)
* mailer.py: add win32 compatibility, plus other bugfixes
- Both:
* new 'locking' feature (issue #1478, see release notes for details):
- new: 'svn lock/unlock', 'svnadmin lslocks/rmlocks', 'svnlook lock'
- new: 'svn:needs-lock' property to enable communication
- 'svn st [-u]' shows local or remote lock overview
- 'svn info wc | URL' shows local or remote lock details
- 'svn commit' sends locks, 'svn up' removes stale locks
- new hook scripts: pre-lock, pre-unlock, post-lock, post-unlock
* speedups for 'svn blame' and other commands (see xdelta in release notes)
* fixed: big 'svn diff/merge URL URL' ops cause httpd timeout (issue #2048)
* fixed: make both svnserve and svn:// urls work with IPv6 (r13235-6)
* continued improvement of localized message translations:
- German, Spanish, Polish, Brazilian Portuguese, Norwegian Bokmål,
Swedish, Traditional Chinese, Simplified Chinese, Korean, Japanese
- more localized messages in all svn-related binaries
Developer-visible changes:
* binary diff algorithm now defaults to xdelta instead of vdelta
* huge number of new APIs:
- new locking APIs in svn_client.h, svn_ra.h, svn_repos.h, svn_fs.h
- new 'flattened' svn_ra.h API, which imitates svn_fs.h (issue #1931)
- new notification API in svn_client.h, svn_wc.h
- http://svn.haxx.se/dev/archive-2005-04/0319.shtml has all API changes
* fs now has its own 'format' file, independent of repos 'format' (r13387)
* improve efficiency of delta combining algorithm (r13016, r13063)
* make all BDB apis take explicit pool parameters (r13198, r13205)
* remove libsvn_fs_base caching of node revisions (r13299)
* libsvn_repos commit editor can now take incoming txn (r13733)
* fixed: mod_dav_svn sending illegal editor-drive (issue #2258)
* pool usage improvements (r12954, 12852, r13386, issue #1310)
* SWIG bindings: better API coverage overall.
- new ruby bindings!
- remove bitrotting swig-java bindings
- perl and python bindings: numerous improvements, see their own logs.
- bindings tests now within svntest framework
* javahl bindings: numerous improvements, see its own logs.
* many improvements to mailer.py and commit-email.pl
* rewrite/improvements to gen-make build system, including VS.NET support
* many improvements to the automated python testsuite (issue #2257)
* book moved to separate repository (http://svn.red-bean.com/svnbook)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.2.0 Release Candidate 1 released.
Posted by Erik Huelsmann <e....@gmx.net>.
> > The first release candidate of Subversion 1.2.0 is ready and available
> > from:
> >
> > http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.tar.gz
> > http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.tar.bz2
> > http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.zip
>
> Can anyone make binaries available for Windows? I read the installation
> notes to build it myself, but I don't have Visual Studio.
Could everybody please stop asking these questions as an immediate reaction
to our release announcements?
Packages will be available for all platforms with regularly released
packages in due time. No need to ask (or pressure as I percieve these
mails).
Thanks in advance,
Erik.
--
Handyrechnung zu hoch? Tipp: SMS und MMS mit GMX
Seien Sie so frei: Alle Infos unter http://www.gmx.net/de/go/freesms
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.2.0 Release Candidate 1 released.
Posted by de...@xodiac.be.
> The first release candidate of Subversion 1.2.0 is ready and available
> from:
>
> http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.tar.gz
> http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.tar.bz2
> http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.zip
Can anyone make binaries available for Windows? I read the installation
notes to build it myself, but I don't have Visual Studio.
Gino.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Problems building Subversion 1.2.0 RC1 on OS X
Posted by Mike Laster <mi...@marketocracy.com>.
On Apr 7, 2005, at 4:53 PM, Ben Reser wrote:
> The first release candidate of Subversion 1.2.0 is ready and available
> from:
>
> http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.tar.gz
> http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.tar.bz2
> http://subversion.tigris.org/tarballs/subversion-1.2.0-rc1.zip
I'm having trouble getting this to build static binaries on OS X.
With 1.1.4 I would configure with:
./configure --with-zlib --with-ssl --with -openssl --without-apache
--without-apxs --enable-all-static
and it would build binaries without dynamically linking to anything but
OS level shared libraries.
With 1.2.0 this same configuration no longer links. It complains about
missing /usr/lib/crt0.0.
It seems OS X *really* doesn't want you to fully static link files so
they make it nearly impossible
by not providing key components.
But I don't really want fully static. I just want it to not
dynamically link against anything that is not
part of the standard OS install so that the svn binaries have no
external dependencies.
I then tried using:
./configure --with-zlib --with-ssl --with-openssl --without-apache
--without-apxs --disable-shared
This almost works, except that it is still dynamically linking against
BerkeleyDB:
otool -Lv svn
svn:
/usr/local/BerkeleyDB.4.3/lib/libdb-4.3.dylib (compatibility
version 0.0.0, current version 0.0.0)
time stamp 1112668813 Mon Apr 4 22:40:13 2005
/usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current
version 5.0.0)
time stamp 1103154356 Wed Dec 15 18:45:56 2004
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0,
current version 324.9.0)
time stamp 1103154355 Wed Dec 15 18:45:55 2004
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 71.1.1)
time stamp 1103154353 Wed Dec 15 18:45:53 2004
/usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7,
current version 0.9.7)
time stamp 1103154391 Wed Dec 15 18:46:31 2004
/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7,
current version 0.9.7)
time stamp 1103154356 Wed Dec 15 18:45:56 2004
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
time stamp 1103154355 Wed Dec 15 18:45:55 2004
How can I compile Subversion to use BerkeleyDB but not dynamically link
to the library?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate 1 released.]
Posted by Ben Reser <be...@reser.org>.
On Fri, Apr 08, 2005 at 03:39:31AM +0200, Branko ??ibej wrote:
> I think it is. It's a quirk that should've been removed ages ago, and we
> don't want to make it permanent by including it in a released version.
> As for restarting the soak... the release candidate was published
> yesterdal. What's one day compared to an eternity of supporting a broken
> feature?
Soak started Monday. Not when the rc was published. So it's closer to
4 days. But I don't really think it's a big deal. Just fix the help
thing in 1.2.1 and let it slide, I thought we agreed to implement:
svn version URL
In which case leaving it in doesn't really hurt anything.
--
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: New "svn version" command [was: Subversion 1.2.0 Release Candidate
1 released.]
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>On Fri, Apr 08, 2005 at 12:58:26AM +0100, Julian Foad wrote:
>
>
>>In fact, I'll veto now: -1 on releasing v1.2 with this in its current state.
>>
>>
>
>You realize that removing this requires us to restart the soak... Is it
>really that important?
>
I think it is. It's a quirk that should've been removed ages ago, and we
don't want to make it permanent by including it in a released version.
As for restarting the soak... the release candidate was published
yesterdal. What's one day compared to an eternity of supporting a broken
feature?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release
Candidate 1 released.]
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-04-07 at 21:32, Ben Reser wrote:
> On Fri, Apr 08, 2005 at 12:58:26AM +0100, Julian Foad wrote:
> > In fact, I'll veto now: -1 on releasing v1.2 with this in its current state.
>
> You realize that removing this requires us to restart the soak... Is it
> really that important?
Why would it require us to restart the soak? According to HACKING, only
destabilizing changes and incompatible API changes require a restart of
the full four-week soak.
(Sorry to come in a bit late here. My main comment on the thread is
that if you're going to justify "svn version" with "svn version URL",
then you need to *actually implement* "svn version URL" first.
Justifying a questionable half-measure with a future improvement is a
recipe for having lots of questionable half-measures in the code base.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate
1 released.]
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Reser wrote:
> On Fri, Apr 08, 2005 at 12:58:26AM +0100, Julian Foad wrote:
>>In fact, I'll veto now: -1 on releasing v1.2 with this in its current state.
>
> You realize that removing this requires us to restart the soak... Is it
> really that important?
I didn't think about that until you pointed it out, but yes, it is that
important. We must not be careless about adding features, and this feature is
not fit for release.
(There is a good chance that we will find enough problems with RC1 that we will
have to re-start the soak period anyway, in which case no single problem will
be directly responsible for the delay.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate 1 released.]
Posted by Ben Reser <be...@reser.org>.
On Fri, Apr 08, 2005 at 12:58:26AM +0100, Julian Foad wrote:
> In fact, I'll veto now: -1 on releasing v1.2 with this in its current state.
You realize that removing this requires us to restart the soak... Is it
really that important?
--
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: New "svn version" command [was: Subversion 1.2.0 ReleaseCandidate 1 released.]
Posted by Max Bowsher <ma...@ukf.net>.
John Peacock wrote:
> Max Bowsher wrote:
>> IMO, this situation is identical to the "svn:keywords canonicalization"
>> one.
>> We have a new feature, which is broken.
>> Reverting it is an improvement over not reverting it, but fixing it
>> would be an improvement over both.
>
> That actually brings up something that I was wondering. The original
> canonicalization patch was reverted in trunk and then on 1.2.x
> (unfortunately on the day the listserv went deaf), before there was a
> chance to discuss fixes. Is this feature now dead for 1.2.0 or can the
> reversion be reverted (since the feature was originally accepted for
> 1.2.0)?
I don't know. Personally, I don't think it's of sufficient urgency to get
into 1.2.
If several people think otherwise, then it could go in.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 ReleaseCandidate
1 released.]
Posted by John Peacock <jp...@rowman.com>.
Max Bowsher wrote:
> IMO, this situation is identical to the "svn:keywords canonicalization"
> one.
> We have a new feature, which is broken.
> Reverting it is an improvement over not reverting it, but fixing it
> would be an improvement over both.
That actually brings up something that I was wondering. The original
canonicalization patch was reverted in trunk and then on 1.2.x
(unfortunately on the day the listserv went deaf), before there was a
chance to discuss fixes. Is this feature now dead for 1.2.0 or can the
reversion be reverted (since the feature was originally accepted for 1.2.0)?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 ReleaseCandidate 1 released.]
Posted by Max Bowsher <ma...@ukf.net>.
Brian W. Fitzpatrick wrote:
> On Fri, 2005-04-08 at 13:49 +0100, Julian Foad wrote:
>> Branko Čibej wrote:
>>> Julian Foad wrote:
>>>> It's not too late. Please rip it out, and propose the reversion for
>>>> back-port into 1.2.0. I forsee at least you, me, Max and Greg voting
>>>> it through.
>>>
>>> Could you do that please? I'll have my hands full with other things for
>>> the next several days, and won't have time to test the change, but I
>>> don't want to extend the 1.2 release schedule.
>>>
>>> Consider this a +1 from me for removing "svn version" from both trunk
>>> and 1.2 branch.
>>
>> Done in r14037, and proposed for back-port to 1.2.0. Please test and
>> vote!
>
> Oy. Is it really necessary to rip this completely out? I think it's
> useful, especially if we, as Ben Reser pointed out, implement
>
> svn version URL
>
> In addition, I saw no consensus on removing it. Aside from Julian and
> Branko, I saw no other +1's on ripping it out (Although you surmised
> that greg and maxb would). Can't we just:
>
> 1. Fix the bug where 'svn version foo' acts like 'svn help foo'
> 2. Add 'version' to the 'svn help' output
>
> and then later we can implement 'svn version URL' at our leisure.
>
> I'm -0.9 on removing it.
Since I'm being speculated upon, I guess I should offer my opinion :-)
IMO, this situation is identical to the "svn:keywords canonicalization" one.
We have a new feature, which is broken.
Reverting it is an improvement over not reverting it, but fixing it would be
an improvement over both.
The issue is, the fix would require new ra_svn and ra_dav methods. Which is
a fairly big thing to backport.
Thoughts?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate 1 released.]
Posted by Molle Bestefich <mo...@gmail.com>.
Brian W. Fitzpatrick wrote:
> Julian Foad wrote:
>> Branko Čibej wrote:
>>> Julian Foad wrote:
>>>> It's not too late. Please rip it out, and propose the reversion for
>>>> back-port into 1.2.0. I forsee at least you, me, Max and Greg voting
>>>> it through.
>>>
>>> Could you do that please? I'll have my hands full with other things for
>>> the next several days, and won't have time to test the change, but I
>>> don't want to extend the 1.2 release schedule.
>>>
>>> Consider this a +1 from me for removing "svn version" from both trunk
>>> and 1.2 branch.
>>
>> Done in r14037, and proposed for back-port to 1.2.0. Please test and vote!
>
> Oy. Is it really necessary to rip this completely out? I think it's
> useful, especially if we, as Ben Reser pointed out, implement
>
> svn version URL
Ok, so let me get this straight.
You want to have a command named 'svnversion' and another one named
'svn version', with completely different purposes?
What are you trying to do, confuse your users deliberately?
> In addition, I saw no consensus on removing it. Aside from Julian and
> Branko, I saw no other +1's on ripping it out (Although you surmised
> that greg and maxb would).
Does anybody really think that it's useful?
Wouldn't it be more sensible to ask people to vote for keeping it in?
My gut feeling is that near to noone would, but how would I know.
How about:
1. Revert this weird hack
2. When somebody gets the time to do this right, implement a 'svn
version' that does what 'svn --version' does, but that supports an
URL. Add --version and -v as a wrapper that doesn't support URL,
seeing as it's basic Unix/whatever syntax and perhaps for backwards
compatibility.
3. And this one's important. At the same time, integrate the
'svnversion' tool in 'svn', and rename it to something else than
version! There's been a good bunch of names suggested earlier..
final note: Having both 'svnversion', 'svn version' and 'svn
--version' is almost hilarious :-)
just my 2c.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0
Release Candidate 1 released.]
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Fri, 2005-04-08 at 18:21 +0200, Branko Čibej wrote:
> To be pedantic, this is trunk not branch, so it's CTR. The voting only
> applies to merges to the branch, so Julian was quite within this rights
> to do what he did.
CTR? Does that mean Commit-Then-Revert? :-)
> If, as you suggest, we go and actually fix this to DTRT, we'll delay the
> soak for weeks, not days. And as someone noted in another post,
> svnversion vs. svn version vs. svn --version is truly weird. So let's
> just rip this whole sad story out of the code and come up with a good
> design for 1.3 (or even earlier, we can always add commands).
Fair enough. I concede. 1.3 it is.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate 1 released.]
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> If, as you suggest, we go and actually fix this to DTRT, we'll delay
> the soak for weeks, not days. And as someone noted in another post,
> svnversion vs. svn version vs. svn --version is truly weird. So let's
> just rip this whole sad story out of the code and come up with a good
> design for 1.3 (or even earlier, we can always add commands).
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate
1 released.]
Posted by Branko Čibej <br...@xbc.nu>.
Brian W. Fitzpatrick wrote:
>On Fri, 2005-04-08 at 13:49 +0100, Julian Foad wrote:
>
>
>>Branko Čibej wrote:
>>
>>
>>>Julian Foad wrote:
>>>
>>>
>>>>It's not too late. Please rip it out, and propose the reversion for
>>>>back-port into 1.2.0. I forsee at least you, me, Max and Greg voting
>>>>it through.
>>>>
>>>>
>>>Could you do that please? I'll have my hands full with other things for
>>>the next several days, and won't have time to test the change, but I
>>>don't want to extend the 1.2 release schedule.
>>>
>>>Consider this a +1 from me for removing "svn version" from both trunk
>>>and 1.2 branch.
>>>
>>>
>>Done in r14037, and proposed for back-port to 1.2.0. Please test and vote!
>>
>>
>
>Oy. Is it really necessary to rip this completely out? I think it's
>useful, especially if we, as Ben Reser pointed out, implement
>
>svn version URL
>
>In addition, I saw no consensus on removing it. Aside from Julian and
>Branko, I saw no other +1's on ripping it out
>
To be pedantic, this is trunk not branch, so it's CTR. The voting only
applies to merges to the branch, so Julian was quite within this rights
to do what he did.
> (Although you surmised
>that greg and maxb would). Can't we just:
>
>1. Fix the bug where 'svn version foo' acts like 'svn help foo'
>2. Add 'version' to the 'svn help' output
>
>and then later we can implement 'svn version URL' at our leisure.
>
>I'm -0.9 on removing it.
>
>
Please note, this was a prototype hack that never should've gone in in
the first place. My bad, etc.
If, as you suggest, we go and actually fix this to DTRT, we'll delay the
soak for weeks, not days. And as someone noted in another post,
svnversion vs. svn version vs. svn --version is truly weird. So let's
just rip this whole sad story out of the code and come up with a good
design for 1.3 (or even earlier, we can always add commands).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release
Candidate 1 released.]
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Fri, 2005-04-08 at 13:49 +0100, Julian Foad wrote:
> Branko Čibej wrote:
> > Julian Foad wrote:
> >> It's not too late. Please rip it out, and propose the reversion for
> >> back-port into 1.2.0. I forsee at least you, me, Max and Greg voting
> >> it through.
> >
> > Could you do that please? I'll have my hands full with other things for
> > the next several days, and won't have time to test the change, but I
> > don't want to extend the 1.2 release schedule.
> >
> > Consider this a +1 from me for removing "svn version" from both trunk
> > and 1.2 branch.
>
> Done in r14037, and proposed for back-port to 1.2.0. Please test and vote!
Oy. Is it really necessary to rip this completely out? I think it's
useful, especially if we, as Ben Reser pointed out, implement
svn version URL
In addition, I saw no consensus on removing it. Aside from Julian and
Branko, I saw no other +1's on ripping it out (Although you surmised
that greg and maxb would). Can't we just:
1. Fix the bug where 'svn version foo' acts like 'svn help foo'
2. Add 'version' to the 'svn help' output
and then later we can implement 'svn version URL' at our leisure.
I'm -0.9 on removing it.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate
1 released.]
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Julian Foad wrote:
>> It's not too late. Please rip it out, and propose the reversion for
>> back-port into 1.2.0. I forsee at least you, me, Max and Greg voting
>> it through.
>
> Could you do that please? I'll have my hands full with other things for
> the next several days, and won't have time to test the change, but I
> don't want to extend the 1.2 release schedule.
>
> Consider this a +1 from me for removing "svn version" from both trunk
> and 1.2 branch.
Done in r14037, and proposed for back-port to 1.2.0. Please test and vote!
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate
1 released.]
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> Branko Čibej wrote:
>
>> Julian Foad wrote:
>>
>>> I'm inclined to propose reverting this unless somebody has a very
>>> good argument to make.
>>
>
> In fact, I'll veto now: -1 on releasing v1.2 with this in its current
> state.
>
>> I'm inclined to agree. Pity I didn't notice this before...
>
>
> It's not too late. Please rip it out, and propose the reversion for
> back-port into 1.2.0. I forsee at least you, me, Max and Greg voting
> it through.
Could you do that please? I'll have my hands full with other things for
the next several days, and won't have time to test the change, but I
don't want to extend the 1.2 release schedule.
Consider this a +1 from me for removing "svn version" from both trunk
and 1.2 branch.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate
1 released.]
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Julian Foad wrote:
>> I'm inclined to propose reverting this unless somebody has a very good
>> argument to make.
In fact, I'll veto now: -1 on releasing v1.2 with this in its current state.
> I'm inclined to agree. Pity I didn't notice this before...
It's not too late. Please rip it out, and propose the reversion for back-port
into 1.2.0. I forsee at least you, me, Max and Greg voting it through.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate
1 released.]
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> Branko Čibej wrote:
>
>>> User-visible-changes:
>>> * new 'svn version' subcommand, essentially same as --version
>>> (r10430)
>>>
>> Ohmigod... is that still in the code? I recall some strong objections
>> against a "svn version" command, and sort of remember our deciding to
>> rip it out again. What gives?
>
>
> I thought it was here to stay because enough people had been adamant
> that it was needed, for reasons something to do with reporting the
> version of the server of a given repository, but it wasn't entirely
> clear and that doesn't appear to have been done.
>
> I don't like the idea of a "svn version" command that is like "svn
> --version". I think the subcommands should all be about versioning
> your files, and the "--version" option was perfectly adequate for
> reporting the client's version.
>
> In fact, the "version" subcommand appears to be a horrible hack, or at
> least to have got mixed up in the horrible hack that currently
> implements "--help" and "--version":
Yes, and It's all my fault...
> ~/src/subversion> svn version http://svn.collab.net/
> "http://svn.collab.net/": unknown command.
>
> ~/src/subversion> svn version add
> add: Put files and directories under version control, scheduling
> them for addition to repository. They will be added in next commit.
> [...]
>
> I'm inclined to propose reverting this unless somebody has a very good
> argument to make.
I'm inclined to agree. Pity I didn't notice this before...
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New "svn version" command [was: Subversion 1.2.0 Release Candidate
1 released.]
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> Branko Čibej wrote:
>> Ohmigod... is that still in the code? I recall some strong objections
>> against a "svn version" command, and sort of remember our deciding to
>> rip it out again. What gives?
Here is one of the original motivations:
http://www.contactor.se/~dast/svn/archive-2003-11/0547.shtml
Another motivation was that "svn help" lists the available commands and
"version" is not one of them. A user pointed out that "It's pretty hard to
find the option '--version' via svn help."
A good solution to that second motivation would of course be to make "svn help"
list the "--version" option. That's a simple bug in my view.
Here is the most relevant recent thread:
http://svn.haxx.se/dev/archive-2004-07/1221.shtml
in which Max Bowsher wrote:
> Greg Hudson wrote:
>> I am close to -1 on it because:
>
> I am +1 on this, if and only if, before 1.2.0, "svn version URL" also shows
> the server version.
>
> CVS has this feature and it is sometimes helpful.
>
>> * I think we need to keep our subcommand count small. If a user
>> wants to figure out how to do something, the list of subcommands
>> is one of the primary places to look. The longer this list, the
>> longer it will take users to find what they want.
>
> Although I agree that our subcommand set size must remain managable, I think
> this addition is worthwhile.
>
>> * Subcommands are typically seen as verbs, not as nouns. So people
>> might get derailed thinking that there is an svn subcommand to
>> "version" a file or directory.
And they might also expect it to show the current version (revision) of their
working copy, as "svnversion" does.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
New "svn version" command [was: Subversion 1.2.0 Release Candidate
1 released.]
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
>> User-visible-changes:
>> * new 'svn version' subcommand, essentially same as --version (r10430)
>>
> Ohmigod... is that still in the code? I recall some strong objections
> against a "svn version" command, and sort of remember our deciding to
> rip it out again. What gives?
I thought it was here to stay because enough people had been adamant that it
was needed, for reasons something to do with reporting the version of the
server of a given repository, but it wasn't entirely clear and that doesn't
appear to have been done.
I don't like the idea of a "svn version" command that is like "svn --version".
I think the subcommands should all be about versioning your files, and the
"--version" option was perfectly adequate for reporting the client's version.
In fact, the "version" subcommand appears to be a horrible hack, or at least to
have got mixed up in the horrible hack that currently implements "--help" and
"--version":
~/src/subversion> svn version http://svn.collab.net/
"http://svn.collab.net/": unknown command.
~/src/subversion> svn version add
add: Put files and directories under version control, scheduling
them for addition to repository. They will be added in next commit.
[...]
I'm inclined to propose reverting this unless somebody has a very good argument
to make.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.2.0 Release Candidate 1 released.
Posted by Mark Phippard <Ma...@softlanding.com>.
Ben Collins-Sussman <su...@collab.net> wrote on 04/08/2005 10:51:24 AM:
>
> On Apr 8, 2005, at 9:24 AM, Mark Phippard wrote:
> >>
> >> By the way, I've put up a FAQ about building mod_dav_svn 1.2 on
win32.
> >> We need to point people to that FAQ until httpd 2.0.54 is released:
> >>
> >> http://subversion.tigris.org/faq.html#windows-mod_dav_svn-build
> >
> > Is there an Apache Bugzilla# for this? I just looked at our mod_dav
on
> > OS/400 and it is missing all of these exports too. I will need to
give
> > something to IBM to point them to what they need to look at.
> >
> >
>
> I don't think so, because it's already been fixed in apache's trunk and
> 2.0 branch.
Is there a ViewCVS-like link to that revision? I searched around the
Apache site and could not find the ViewCVS URL.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.2.0 Release Candidate 1 released.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 8, 2005, at 9:24 AM, Mark Phippard wrote:
>>
>> By the way, I've put up a FAQ about building mod_dav_svn 1.2 on win32.
>> We need to point people to that FAQ until httpd 2.0.54 is released:
>>
>> http://subversion.tigris.org/faq.html#windows-mod_dav_svn-build
>
> Is there an Apache Bugzilla# for this? I just looked at our mod_dav on
> OS/400 and it is missing all of these exports too. I will need to give
> something to IBM to point them to what they need to look at.
>
>
I don't think so, because it's already been fixed in apache's trunk and
2.0 branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.2.0 Release Candidate 1 released.
Posted by Mark Phippard <Ma...@softlanding.com>.
Ben Collins-Sussman <su...@collab.net> wrote on 04/08/2005 10:06:10 AM:
> On Apr 8, 2005, at 12:33 AM, Sander Striker wrote:
>
> > Branko Čibej wrote:
> >> Ben Reser wrote:
> >>> The term 'release candidate' means the Subversion developers feel
> >>> that
> >>> this release is stable and ready for production use, so we encourage
> >>> people to test this release thoroughly. The final 1.2.0 release is
> >>> scheduled for early-May, in order to provide plenty of time for
> >>> testing.
> >>>
> >> Well, without mod_(dav|authz)_svn on Windows, unless there's an
> >> httpd-2.0.54 release (with my mod_dav patch included) in the
> >> meantime. Sander, any news on that front?
> >
> > The news is that I will start the T&R on 2.0.54 this week aka
somewhere
> > today. However, the tarball will have to pass QA which could cause
> > another iteration, etc., so I'm not committing myself to a date.
> >
>
> By the way, I've put up a FAQ about building mod_dav_svn 1.2 on win32.
> We need to point people to that FAQ until httpd 2.0.54 is released:
>
> http://subversion.tigris.org/faq.html#windows-mod_dav_svn-build
Is there an Apache Bugzilla# for this? I just looked at our mod_dav on
OS/400 and it is missing all of these exports too. I will need to give
something to IBM to point them to what they need to look at.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.2.0 Release Candidate 1 released.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 8, 2005, at 12:33 AM, Sander Striker wrote:
> Branko Čibej wrote:
>> Ben Reser wrote:
>>> The term 'release candidate' means the Subversion developers feel
>>> that
>>> this release is stable and ready for production use, so we encourage
>>> people to test this release thoroughly. The final 1.2.0 release is
>>> scheduled for early-May, in order to provide plenty of time for
>>> testing.
>>>
>> Well, without mod_(dav|authz)_svn on Windows, unless there's an
>> httpd-2.0.54 release (with my mod_dav patch included) in the
>> meantime. Sander, any news on that front?
>
> The news is that I will start the T&R on 2.0.54 this week aka somewhere
> today. However, the tarball will have to pass QA which could cause
> another iteration, etc., so I'm not committing myself to a date.
>
By the way, I've put up a FAQ about building mod_dav_svn 1.2 on win32.
We need to point people to that FAQ until httpd 2.0.54 is released:
http://subversion.tigris.org/faq.html#windows-mod_dav_svn-build
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.2.0 Release Candidate 1 released.
Posted by Sander Striker <st...@apache.org>.
Branko Čibej wrote:
> Ben Reser wrote:
>
>> The term 'release candidate' means the Subversion developers feel that
>> this release is stable and ready for production use, so we encourage
>> people to test this release thoroughly. The final 1.2.0 release is
>> scheduled for early-May, in order to provide plenty of time for
>> testing.
>>
>>
> Well, without mod_(dav|authz)_svn on Windows, unless there's an
> httpd-2.0.54 release (with my mod_dav patch included) in the meantime.
> Sander, any news on that front?
The news is that I will start the T&R on 2.0.54 this week aka somewhere
today. However, the tarball will have to pass QA which could cause
another iteration, etc., so I'm not committing myself to a date.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.2.0 Release Candidate 1 released.
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>The term 'release candidate' means the Subversion developers feel that
>this release is stable and ready for production use, so we encourage
>people to test this release thoroughly. The final 1.2.0 release is
>scheduled for early-May, in order to provide plenty of time for
>testing.
>
>
Well, without mod_(dav|authz)_svn on Windows, unless there's an
httpd-2.0.54 release (with my mod_dav patch included) in the meantime.
Sander, any news on that front?
>--------------------8-<-------cut-here---------8-<-----------------------
> User-visible-changes:
> - Client:
> * new 'svn version' subcommand, essentially same as --version (r10430)
>
>
Ohmigod... is that still in the code? I recall some strong objections
against a "svn version" command, and sort of remember our deciding to
rip it out again. What gives?
> Developer-visible changes:
>
>
* New packaging script for Windows (build/win32/make_dist.py)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.2.0 Release Candidate 1 released.
Posted by Jan Bares <he...@yahoo.com>.
Hi,
> http://subversion.tigris.org/svn_1.2_releasenotes.html
has typo in "encyrypted".
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org