Re: Subversion 1.6.18 released
On Fri, Apr 13, 2012 at 10:38:52PM +0200, Johan Corveleyn wrote: On Thu, Apr 12, 2012 at 3:15 PM, Stefan Sperling s...@apache.org wrote: I'm happy to announce the release of Apache Subversion 1.6.18. [...] For this release, the following people have provided PGP signatures: C. Michael Pilato [1024D/1706FD6E] with fingerprint: 20BF 14DC F02F 2730 7EA4 C7BB A241 06A9 1706 FD6E Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Paul T. Burba [1024D/53FCDC55] with fingerprint: E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55 Stefan Sperling [1024D/F59D25F0] with fingerprint: B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0 Blair Zajac [1024D/DA561D91] with fingerprint: 3FAE C7E1 ADE8 572F 613C F086 C572 2326 DA56 1D91 Hi Stefan, Seems you missed/forgot my signature [1]. No biggie, just thought I'd mention it. Or maybe I did something wrong? [1] http://svn.haxx.se/dev/archive-2012-04/0003.shtml The release.py script missed it somehow. Sorry about that. Your sig is present in subversion-1.6.18.zip.asc. It contains windows line endings while the other sigs in the file use Unix line endings. Maybe this is what's causing release.py to miss the signature? I suppose in the future we should mark the .asc files as text instead of binary and set their eol-style to 'native'.
Re: Subversion 1.6.18 released
Stefan Sperling wrote on Sat, Apr 14, 2012 at 15:32:04 +0200: I suppose in the future we should mark the .asc files as text instead of binary and set their eol-style to 'native'. Agreed. r1326103
Ev2 and Authz
Good morning (in some parts of the world)! I've been doing some poking around with Ev2 and copy operations on the ev2-export branch, and have some observations which merit discussion. In the working copy and elsewhere, all versioned nodes map to a repos_relpath, and I've found it greatly simplifies things if we use that repos relpath in Ev2 operations. Since an Ev2 drive doesn't need to be anchored anywhere, using the repos_relpath in this way is analogous to using local_abspaths throughout the working copy, giving every node a single canonical name. However, this has implications in the world of the dreaded issue 3242. For instance, if a session is parented at the root, where the user cannot write, then executes write operations somewhere deep in the tree, where the user does have write privileges, we will produce errors. This is obviously non-sensical and undesirable. If somebody can write to /A/B/C/D, they should be able to open an ra_session to any of the parents and write to their allowable paths without consequence. I know this problem has been known for some time; has anybody looked at what it would take to solve it? -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
svn_checksum__from_digest() core dump on invalid input
In tracking down spurious coredumps we have in our custom RPC server, I found
one in svn_checksum__from_digest() due to bad input:
svn_checksum_t *
svn_checksum__from_digest(const unsigned char *digest,
svn_checksum_kind_t kind,
apr_pool_t *result_pool)
{
svn_checksum_t *checksum = svn_checksum_create(kind, result_pool);
memcpy((unsigned char *)checksum-digest, digest, DIGESTSIZE(kind));
return checksum;
}
If kind is invalid, then svn_checksum_create() returns NULL, which then
coredumps in memcpy().
Normally, I would change svn_checksum__from_digest() to
svn_error_t *
svn_checksum__from_digest(svn_checksum_t **checksum,
const unsigned char *digest,
svn_checksum_kind_t kind,
apr_pool_t *result_pool);
but I'm wondering how the checksum code needs to handle newer checksums in older
Subversion servers? Say 1.9 adds sha224 and then we read the repos in 1.7, how
should svn handle this? Should it throw a SVN_ERR_BAD_CHECKSUM_KIND or silently
map an unknown checksum to NULL? Do we want to conditionally support checksums
depending upon repository version?
Frankly, I'm happy I got a core dump in our code since it prevented bad data
from being used. My feeling is that the bad data is coming from a cache entry
that is released but something has a pointer to it still.
Blair
Re: Subversion 1.6.18 released
On Sat, Apr 14, 2012 at 3:32 PM, Stefan Sperling s...@apache.org wrote: On Fri, Apr 13, 2012 at 10:38:52PM +0200, Johan Corveleyn wrote: On Thu, Apr 12, 2012 at 3:15 PM, Stefan Sperling s...@apache.org wrote: I'm happy to announce the release of Apache Subversion 1.6.18. [...] For this release, the following people have provided PGP signatures: C. Michael Pilato [1024D/1706FD6E] with fingerprint: 20BF 14DC F02F 2730 7EA4 C7BB A241 06A9 1706 FD6E Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Paul T. Burba [1024D/53FCDC55] with fingerprint: E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55 Stefan Sperling [1024D/F59D25F0] with fingerprint: B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0 Blair Zajac [1024D/DA561D91] with fingerprint: 3FAE C7E1 ADE8 572F 613C F086 C572 2326 DA56 1D91 Hi Stefan, Seems you missed/forgot my signature [1]. No biggie, just thought I'd mention it. Or maybe I did something wrong? [1] http://svn.haxx.se/dev/archive-2012-04/0003.shtml The release.py script missed it somehow. Sorry about that. Your sig is present in subversion-1.6.18.zip.asc. It contains windows line endings while the other sigs in the file use Unix line endings. Maybe this is what's causing release.py to miss the signature? Ah yes, that's probably it. Strange though that this hasn't come up before. I signed 1.7.4 as well, and there my signature was picked up correctly. Or maybe it's a new feature of release.py to scrape this automatically? BTW, I use a gpg executable built for Windows (so no Cygwin version or something like that). So apparently that produces Windows line endings by default. I suppose in the future we should mark the .asc files as text instead of binary and set their eol-style to 'native'. Yes. Thanks, danielsh :-). -- Johan
Use 1.7.7 for next release (was: Re: 1.7.5 in one/two weeks?)
2012/4/12 Daniel Shahaf danie...@apache.org: We released 1.6.18 today and 1.7.4 just over a month ago. There are a few useful items merged already, and STATUS has a truckload of pending changes. Shall we roll 1.7.5 in two weeks from today? If we can clear STATUS and roll next Thursday that's fine too, but I don't think we're in a hurry. Hi! I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. There is a lot of Subversion exception! threads on users@ where TortoiseSVN version is visible. For example [1]. I think skipping those already used numbers will lessen confusion. [1] http://markmail.org/message/p6d6ih2p2rzegpi7 Best regards, Konstantin Kolinko
Re: Use 1.7.7 for next release (was: Re: 1.7.5 in one/two weeks?)
On 4/14/12 12:24 PM, Konstantin Kolinko wrote: 2012/4/12 Daniel Shahafdanie...@apache.org: We released 1.6.18 today and 1.7.4 just over a month ago. There are a few useful items merged already, and STATUS has a truckload of pending changes. Shall we roll 1.7.5 in two weeks from today? If we can clear STATUS and roll next Thursday that's fine too, but I don't think we're in a hurry. Hi! I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. There is a lot of Subversion exception! threads on users@ where TortoiseSVN version is visible. For example [1]. I think skipping those already used numbers will lessen confusion. Since Subversion is the base project, I would rather see TortoiseSVN change it's versioning to match ours than the other way. TortoiseSVN could add an additional version number after Subversion's, e.g. 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4, 1.7.4-tsvn2 for the second, etc. Blair
Re: Use 1.7.7 for next release (was: Re: 1.7.5 in one/two weeks?)
On Sat, Apr 14, 2012 at 2:31 PM, Blair Zajac bl...@orcaware.com wrote: On 4/14/12 12:24 PM, Konstantin Kolinko wrote: 2012/4/12 Daniel Shahafdanie...@apache.org: We released 1.6.18 today and 1.7.4 just over a month ago. There are a few useful items merged already, and STATUS has a truckload of pending changes. Shall we roll 1.7.5 in two weeks from today? If we can clear STATUS and roll next Thursday that's fine too, but I don't think we're in a hurry. Hi! I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. There is a lot of Subversion exception! threads on users@ where TortoiseSVN version is visible. For example [1]. I think skipping those already used numbers will lessen confusion. Since Subversion is the base project, I would rather see TortoiseSVN change it's versioning to match ours than the other way. TortoiseSVN could add an additional version number after Subversion's, e.g. 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4, 1.7.4-tsvn2 for the second, etc. Agreed. Adapting Subversion version numbers to accomodate arbitrary downstream projects is a slippery slope toward madness. It feels like there is a reporting issue, more than a version number issue. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: Use 1.7.7 for next release (was: Re: 1.7.5 in one/two weeks?)
On Sat, Apr 14, 2012 at 15:31, Blair Zajac bl...@orcaware.com wrote: On 4/14/12 12:24 PM, Konstantin Kolinko wrote: 2012/4/12 Daniel Shahafdanie...@apache.org: We released 1.6.18 today and 1.7.4 just over a month ago. There are a few useful items merged already, and STATUS has a truckload of pending changes. Shall we roll 1.7.5 in two weeks from today? If we can clear STATUS and roll next Thursday that's fine too, but I don't think we're in a hurry. Hi! I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. There is a lot of Subversion exception! threads on users@ where TortoiseSVN version is visible. For example [1]. I think skipping those already used numbers will lessen confusion. Since Subversion is the base project, I would rather see TortoiseSVN change it's versioning to match ours than the other way. TortoiseSVN could add an additional version number after Subversion's, e.g. 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4, 1.7.4-tsvn2 for the second, etc. Or 1.7.4.0, 1.7.4.1, 1.7.4.2 ... etc Most Windows binaries have four components anyway, right? Cheers, -g
Re: Use 1.7.7 for next release
On 14.04.2012 21:31, Blair Zajac wrote: On 4/14/12 12:24 PM, Konstantin Kolinko wrote: 2012/4/12 Daniel Shahafdanie...@apache.org: We released 1.6.18 today and 1.7.4 just over a month ago. There are a few useful items merged already, and STATUS has a truckload of pending changes. Shall we roll 1.7.5 in two weeks from today? If we can clear STATUS and roll next Thursday that's fine too, but I don't think we're in a hurry. Hi! I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. There is a lot of Subversion exception! threads on users@ where TortoiseSVN version is visible. For example [1]. I think skipping those already used numbers will lessen confusion. Since Subversion is the base project, I would rather see TortoiseSVN change it's versioning to match ours than the other way. TortoiseSVN could add an additional version number after Subversion's, e.g. 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4, 1.7.4-tsvn2 for the second, etc. The TSVN installer already mentions the SVN version number in its file name, e.g. TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi = And the last few 1.6.x releases also didn't have matching version numbers, e.g. TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi So that wasn't a problem back then. Why is it now? Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net
Re: Use 1.7.7 for next release
On Sat, Apr 14, 2012 at 16:15, Stefan Küng tortoise...@gmail.com wrote: On 14.04.2012 21:31, Blair Zajac wrote: On 4/14/12 12:24 PM, Konstantin Kolinko wrote: 2012/4/12 Daniel Shahafdanie...@apache.org: We released 1.6.18 today and 1.7.4 just over a month ago. There are a few useful items merged already, and STATUS has a truckload of pending changes. Shall we roll 1.7.5 in two weeks from today? If we can clear STATUS and roll next Thursday that's fine too, but I don't think we're in a hurry. Hi! I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. There is a lot of Subversion exception! threads on users@ where TortoiseSVN version is visible. For example [1]. I think skipping those already used numbers will lessen confusion. Since Subversion is the base project, I would rather see TortoiseSVN change it's versioning to match ours than the other way. TortoiseSVN could add an additional version number after Subversion's, e.g. 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4, 1.7.4-tsvn2 for the second, etc. The TSVN installer already mentions the SVN version number in its file name, e.g. TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi = And the last few 1.6.x releases also didn't have matching version numbers, e.g. TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi So that wasn't a problem back then. Why is it now? Konstantin suggested we change Subversion to deal with the discrepancy, rather than changing TSVN. People felt that was the wrong direction of change... I have to say: it *does* make things a bit harder on the users@ mailing list. What? 1.7.5 has not been released yet. Were you testing with the unreleased tarball?! Did somebody release that tarball? Cheers, -g
Re: Use 1.7.7 for next release
On 14.04.2012 22:28, Greg Stein wrote: I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. There is a lot of Subversion exception! threads on users@ where TortoiseSVN version is visible. For example [1]. I think skipping those already used numbers will lessen confusion. Since Subversion is the base project, I would rather see TortoiseSVN change it's versioning to match ours than the other way. TortoiseSVN could add an additional version number after Subversion's, e.g. 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4, 1.7.4-tsvn2 for the second, etc. The TSVN installer already mentions the SVN version number in its file name, e.g. TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi = And the last few 1.6.x releases also didn't have matching version numbers, e.g. TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi So that wasn't a problem back then. Why is it now? Konstantin suggested we change Subversion to deal with the discrepancy, rather than changing TSVN. People felt that was the wrong direction of change... I have to say: it *does* make things a bit harder on the users@ mailing list. What? 1.7.5 has not been released yet. Were you testing with the unreleased tarball?! Did somebody release that tarball? Ok, I see the problem. But what should I do? I can't name the next TSVN release 1.7.5 since the current TSVN version is already 1.7.6 - going back one version would confuse users even more, and would also completely break the update check function TSVN has. Suggestions? Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net
Re: Use 1.7.7 for next release
On 14.04.2012 22:40, Hyrum K Wright wrote: On Sat, Apr 14, 2012 at 3:36 PM, Stefan Küngtortoise...@gmail.com wrote: On 14.04.2012 22:28, Greg Stein wrote: I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. There is a lot of Subversion exception! threads on users@ where TortoiseSVN version is visible. For example [1]. I think skipping those already used numbers will lessen confusion. Since Subversion is the base project, I would rather see TortoiseSVN change it's versioning to match ours than the other way. TortoiseSVN could add an additional version number after Subversion's, e.g. 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4, 1.7.4-tsvn2 for the second, etc. The TSVN installer already mentions the SVN version number in its file name, e.g. TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi = And the last few 1.6.x releases also didn't have matching version numbers, e.g. TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi So that wasn't a problem back then. Why is it now? Konstantin suggested we change Subversion to deal with the discrepancy, rather than changing TSVN. People felt that was the wrong direction of change... I have to say: it *does* make things a bit harder on the users@ mailing list. What? 1.7.5 has not been released yet. Were you testing with the unreleased tarball?! Did somebody release that tarball? Ok, I see the problem. But what should I do? I can't name the next TSVN release 1.7.5 since the current TSVN version is already 1.7.6 - going back one version would confuse users even more, and would also completely break the update check function TSVN has. Suggestions? I think the previously-mentioned suggestion to use a fourth value in the version tuple is an excellent one. Just keep incrementing it until you get back to parity with upstream releases. We already use the fourth value: that's the svn revision number of the working copy at the time of the release build. While I can in the future just use those for 'interim' releases (i.e., releases that are out-of-sync with svn releases), that won't help with the current situation. I can't go back a version. So I'll keep the first three version numbers the same in the future for interim releases (in case I have to create one). But I guess if you want to improve the current situation, there's not much I can do. Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net
Re: Use 1.7.7 for next release
On Apr 14, 2012 4:46 PM, Stefan Küng tortoise...@gmail.com wrote: On 14.04.2012 22:40, Hyrum K Wright wrote: On Sat, Apr 14, 2012 at 3:36 PM, Stefan Küngtortoise...@gmail.com wrote: On 14.04.2012 22:28, Greg Stein wrote: I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. There is a lot of Subversion exception! threads on users@ where TortoiseSVN version is visible. For example [1]. I think skipping those already used numbers will lessen confusion. Since Subversion is the base project, I would rather see TortoiseSVN change it's versioning to match ours than the other way. TortoiseSVN could add an additional version number after Subversion's, e.g. 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4, 1.7.4-tsvn2 for the second, etc. The TSVN installer already mentions the SVN version number in its file name, e.g. TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi = And the last few 1.6.x releases also didn't have matching version numbers, e.g. TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi So that wasn't a problem back then. Why is it now? Konstantin suggested we change Subversion to deal with the discrepancy, rather than changing TSVN. People felt that was the wrong direction of change... I have to say: it *does* make things a bit harder on the users@ mailing list. What? 1.7.5 has not been released yet. Were you testing with the unreleased tarball?! Did somebody release that tarball? Ok, I see the problem. But what should I do? I can't name the next TSVN release 1.7.5 since the current TSVN version is already 1.7.6 - going back one version would confuse users even more, and would also completely break the update check function TSVN has. Suggestions? I think the previously-mentioned suggestion to use a fourth value in the version tuple is an excellent one. Just keep incrementing it until you get back to parity with upstream releases. We already use the fourth value: that's the svn revision number of the working copy at the time of the release build. While I can in the future just use those for 'interim' releases (i.e., releases that are out-of-sync with svn releases), that won't help with the current situation. I can't go back a version. So I'll keep the first three version numbers the same in the future for interim releases (in case I have to create one). But I guess if you want to improve the current situation, there's not much I can do. Hyrum is suggesting we release 1.7.5, and you release 1.7.6.1. Then we release 1.7.6, and tsvn goes to 1.7.6.2. Then we both bump to 1.7.7. Cheers, -g
Re: Use 1.7.7 for next release
On 14.04.2012 23:46, Greg Stein wrote: So I'll keep the first three version numbers the same in the future for interim releases (in case I have to create one). But I guess if you want to improve the current situation, there's not much I can do. Hyrum is suggesting we release 1.7.5, and you release 1.7.6.1. Then we release 1.7.6, and tsvn goes to 1.7.6.2. Then we both bump to 1.7.7. Ok, but the TSVN version will have to be named 1.7.6-2, not 1.7.6.2 because the fourth number is the build revision. It's important that the fourth number keeps increasing with every version, otherwise the msi won't install correctly (we actually swap the third and fourth number for the msi because of that, otherwise nightly builds wouldn't install properly). Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net
Re: Use 1.7.7 for next release
On Sat, Apr 14, 2012 at 5:52 PM, Stefan Küng tortoise...@gmail.com wrote: On 14.04.2012 23:46, Greg Stein wrote: So I'll keep the first three version numbers the same in the future for interim releases (in case I have to create one). But I guess if you want to improve the current situation, there's not much I can do. Hyrum is suggesting we release 1.7.5, and you release 1.7.6.1. Then we release 1.7.6, and tsvn goes to 1.7.6.2. Then we both bump to 1.7.7. Ok, but the TSVN version will have to be named 1.7.6-2, not 1.7.6.2 because the fourth number is the build revision. It's important that the fourth number keeps increasing with every version, otherwise the msi won't install correctly (we actually swap the third and fourth number for the msi because of that, otherwise nightly builds wouldn't install properly). FWIW, I would say just do whatever you want. People will figure it out. I do not see that this is a problem. Your downloads and about dialog are very clear about the Subversion version. With Subclipse we use odd/even version numbering so our current version is 1.8.7. We have never tried to align with the Subversion release number. That would be pointless as it would imply we can only do releases when there are Subversion releases. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Use 1.7.7 for next release (was: Re: 1.7.5 in one/two weeks?)
Konstantin Kolinko wrote on Sat, Apr 14, 2012 at 23:24:57 +0400: 2012/4/12 Daniel Shahaf danie...@apache.org: We released 1.6.18 today and 1.7.4 just over a month ago. There are a few useful items merged already, and STATUS has a truckload of pending changes. Shall we roll 1.7.5 in two weeks from today? If we can clear STATUS and roll next Thursday that's fine too, but I don't think we're in a hurry. Hi! I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. To summarize, the next release will be called 1.7.5 and Stefan Küng will change tsvn's versioning scheme to %d.%d.%d-%d % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH, tsvn_counter++). Thanks for raising this (and thanks Stefan for the fix his end). Daniel
Faster build/check times
Trying to enumerate ways to reduce build times. Faster builds: - export CONFIG_SHELL=/bin/sh (minimal sh preferred) - out-of-tree build (i.e., run 'configure' in an empty dir), with the build tree in a tmpfs - disable unneeded components (eg, swig, bdb) when they're not needed - pass '-q' to configure, '-s' to make - pass '-C' to configure - pass '-j' or '-j[number]' to make - use cpuset(1)/taskset(1) to bind make to N-1 CPUs Faster checks: - PARALLEL=1 - CLEANUP= (and rm -rf svn-test-work/ before the build) - put svn-test-work/ in a tmpfs - SET_LOG_LEVEL=WARN (or ERROR) What else? Thanks, Daniel
