Re: svn commit: r1383214 - in /subversion/trunk: build.conf tools/fsfs/ tools/fsfs/reorg.c
On Tue, Sep 11, 2012 at 4:14 AM, Blair Zajac bl...@orcaware.com wrote: On 9/10/12 6:42 PM, stef...@apache.org wrote: Author: stefan2 Date: Tue Sep 11 01:42:01 2012 New Revision: 1383214 URL: http://svn.apache.org/viewvc?**rev=1383214view=revhttp://svn.apache.org/viewvc?rev=1383214view=rev Log: Add a very early prototype of an FSFS pack optimization tool. * tools/fsfs (new folder) Suggest one of two things with this new directory: 1) Move move all fsfs specific files in there. I see the following at a minimum: tools/server-side/fsfs-**reshard.py tools/server-side/svn-rep-**sharing-stats.c 2) Consider putting this tool in tools/server-side and renaming it fsfs-reorg.c. Moved and renamed in r1389302. -- Stefan^2. -- * Join us this October at Subversion Live 2012http://www.wandisco.com/svn-live-2012 for two days of best practice SVN training, networking, live demos, committer meet and greet, and more! Space is limited, so get signed up todayhttp://www.wandisco.com/svn-live-2012 ! *
Re: Apache Subversion Wiki
On Sat, Sep 22, 2012 at 01:59:43AM +0100, Ethan Cane wrote: Hi there, Is it possible I could receive editing rights on the Apache Subversion Wiki. I'd like very much to make contributions and support the Subversion software project. If permitted then a username of 'EthanCane' would prove ideal. Regards Ethan Cane http://svnmate.com/ Hi Ethan, please register an account with the wiki on this page: http://wiki.apache.org/subversion/ContributorsGroup?action=newaccount I'll then grant your account the necessary editing permissions. Looking forward to your contributions. Thanks!
Re: [svnbench] Revision: 1389172 compiled Sep 24 2012, 00:21:39 on x86_64-unknown-linux-gnu
And auto-upgrade strikes again. #hatethisnonfeature On 09/23/2012 08:33 PM, ne...@apache.org wrote: subversion/libsvn_wc/revision_status.c:64: (apr_err=155021) subversion/libsvn_wc/wc_db.c:12198: (apr_err=155021) subversion/libsvn_wc/wc_db_wcroot.c:609: (apr_err=155021) subversion/libsvn_wc/wc_db_wcroot.c:266: (apr_err=155021) svn: E155021: This client is too old to work with the working copy at '/home/neels/pat/trunk/src' (format 30). You need to get a newer Subversion client. For more details, see http://subversion.apache.org/faq.html#working-copy-format-change [...] -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: [svnbench] Revision: 1389172 compiled Sep 24 2012, 00:21:39 on x86_64-unknown-linux-gnu
C. Michael Pilato cmpil...@collab.net writes: And auto-upgrade strikes again. #hatethisnonfeature On 09/23/2012 08:33 PM, ne...@apache.org wrote: subversion/libsvn_wc/revision_status.c:64: (apr_err=155021) subversion/libsvn_wc/wc_db.c:12198: (apr_err=155021) subversion/libsvn_wc/wc_db_wcroot.c:609: (apr_err=155021) subversion/libsvn_wc/wc_db_wcroot.c:266: (apr_err=155021) svn: E155021: This client is too old to work with the working copy at '/home/neels/pat/trunk/src' (format 30). You need to get a newer Subversion client. For more details, see http://subversion.apache.org/faq.html#working-copy-format-change Before 1.7 the auto-upgrade only happened on write operations. Every time the entries file was read it was auto-upgraded into memory but that change only became permanent when the write operation wrote the memory back to disk. For a read operation the memory was simply discarded. I suppose it might be possible to do something similar with 1.8. If we distinguish read and write operations when opening the database then we could start an extra transaction for read operations that never gets committed. All the subsequent read transactions would be nested within the uncommitted transaction. Then when the read operation closes the database the upgrade within the transaction gets discarded. Does that sound plausible? -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: [svnbench] Revision: 1389172 compiled Sep 24 2012, 00:21:39 on x86_64-unknown-linux-gnu
Is it just a bug in the test script, whereby it uses the just-compiled svn instead of /usr/bin/svn? C. Michael Pilato wrote on Mon, Sep 24, 2012 at 11:32:03 -0400: And auto-upgrade strikes again. #hatethisnonfeature On 09/23/2012 08:33 PM, ne...@apache.org wrote: subversion/libsvn_wc/revision_status.c:64: (apr_err=155021) subversion/libsvn_wc/wc_db.c:12198: (apr_err=155021) subversion/libsvn_wc/wc_db_wcroot.c:609: (apr_err=155021) subversion/libsvn_wc/wc_db_wcroot.c:266: (apr_err=155021) svn: E155021: This client is too old to work with the working copy at '/home/neels/pat/trunk/src' (format 30). You need to get a newer Subversion client. For more details, see http://subversion.apache.org/faq.html#working-copy-format-change [...] -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development
Re: [svnbench] Revision: 1389172 compiled Sep 24 2012, 00:21:39 on x86_64-unknown-linux-gnu
On 09/24/2012 12:23 PM, Philip Martin wrote: Daniel Shahaf d...@daniel.shahaf.name writes: Is it just a bug in the test script, whereby it uses the just-compiled svn instead of /usr/bin/svn? C. Michael Pilato wrote on Mon, Sep 24, 2012 at 11:32:03 -0400: And auto-upgrade strikes again. #hatethisnonfeature On 09/23/2012 08:33 PM, ne...@apache.org wrote: subversion/libsvn_wc/revision_status.c:64: (apr_err=155021) subversion/libsvn_wc/wc_db.c:12198: (apr_err=155021) subversion/libsvn_wc/wc_db_wcroot.c:609: (apr_err=155021) subversion/libsvn_wc/wc_db_wcroot.c:266: (apr_err=155021) svn: E155021: This client is too old to work with the working copy at '/home/neels/pat/trunk/src' (format 30). You need to get a newer Subversion client. For more details, see http://subversion.apache.org/faq.html#working-copy-format-change [...] The code that locates the working copy root will upgrade an unrelated working copy if it has to examine it. svn1.7 co URL wc1.7 svn1.8 co URL wc/nested causes wc1.7 to be upgraded. That's correct. And Philip, I see this as really two issues: 1. we auto-upgrade working copies (at all) 2. we auto-upgrade working copies that are arguably not the true targets of an operation. I can live with the first problem if I must. It's the second that's the more egregious of the two, in my book. So yes, I think it makes (as you suggested elsethread) to add a 'read-only' mode to the WCDB, and to use that mode in the initial exploratory phases of a checkout operation. Maybe we provide a way to upgrade that to read/write programmatically rather than closing and re-opening the DB ... no opinion there. Whatever makes the most sense. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: [svnbench] Revision: 1389172 compiled Sep 24 2012, 00:21:39 on x86_64-unknown-linux-gnu
On Mon, Sep 24, 2012 at 01:50:36PM -0400, C. Michael Pilato wrote: That's correct. And Philip, I see this as really two issues: 1. we auto-upgrade working copies (at all) 2. we auto-upgrade working copies that are arguably not the true targets of an operation. I can live with the first problem if I must. It's the second that's the more egregious of the two, in my book. So yes, I think it makes (as you suggested elsethread) to add a 'read-only' mode to the WCDB, and to use that mode in the initial exploratory phases of a checkout operation. Maybe we provide a way to upgrade that to read/write programmatically rather than closing and re-opening the DB ... no opinion there. Whatever makes the most sense. Or we just disable auto-upgrade. I think we've seen enough reasons now why it's just a plain stupid idea in practice. It it supposed to help users with gazillions of working copies that they have lying around and want to use with a newly installed svn client, and who don't have enough time to type 'svn upgrade' when they want to start using one of their old working copies. [*] And it annoys everyone else, as far as I can tell. [*] That's the only reason for its existence that I've heard, to date.
Re: [svnbench] Revision: 1389172 compiled Sep 24 2012, 00:21:39 on x86_64-unknown-linux-gnu
On Mon, Sep 24, 2012 at 10:03 PM, Stefan Sperling s...@elego.de wrote: On Mon, Sep 24, 2012 at 01:50:36PM -0400, C. Michael Pilato wrote: That's correct. And Philip, I see this as really two issues: 1. we auto-upgrade working copies (at all) 2. we auto-upgrade working copies that are arguably not the true targets of an operation. I can live with the first problem if I must. It's the second that's the more egregious of the two, in my book. So yes, I think it makes (as you suggested elsethread) to add a 'read-only' mode to the WCDB, and to use that mode in the initial exploratory phases of a checkout operation. Maybe we provide a way to upgrade that to read/write programmatically rather than closing and re-opening the DB ... no opinion there. Whatever makes the most sense. Or we just disable auto-upgrade. I think we've seen enough reasons now why it's just a plain stupid idea in practice. +1 to disable auto-upgrade. WC upgrade is non reversible operation and performing it silently is very bad idea. It it supposed to help users with gazillions of working copies that they have lying around and want to use with a newly installed svn client, and who don't have enough time to type 'svn upgrade' when they want to start using one of their old working copies. [*] And it annoys everyone else, as far as I can tell. [*] That's the only reason for its existence that I've heard, to date. -- Ivan Zhakov
Re: buildbot failure in ASF Buildbot on svn-x64-ubuntu-gcc
On Wed, Sep 19, 2012 at 2:14 AM, Philip Martin philip.mar...@wandisco.com wrote: In build/ac-macros/swig.m4 the -ansi flag is explicltly removed for the Ruby bindings so that gcc accepts things like that. Thanks, that worked. I've committed something to that effect in r1389658. I also tracked down the root cause in SWIG and submitted a bug report with a patch attached so they can resolve the problem: https://sourceforge.net/tracker/?func=detailaid=3571361group_id=1645atid=101645
Re: buildbot failure in ASF Buildbot on svn-x64-ubuntu-gcc
On Mon, Sep 24, 2012 at 8:02 PM, Ben Reser b...@reser.org wrote: On Wed, Sep 19, 2012 at 2:14 AM, Philip Martin philip.mar...@wandisco.com wrote: In build/ac-macros/swig.m4 the -ansi flag is explicltly removed for the Ruby bindings so that gcc accepts things like that. Thanks, that worked. I've committed something to that effect in r1389658. I also tracked down the root cause in SWIG and submitted a bug report with a patch attached so they can resolve the problem: https://sourceforge.net/tracker/?func=detailaid=3571361group_id=1645atid=101645 The svn-x64-ubuntu-gcc bot currently lives in my basement, and was recently upgraded to the latest Ubuntu beta release, which bumped a number of dependency versions. The biggest issue with the bindings is the bump to Ruby 1.9 which we explicitly don't support because the tests are not currently compatible with it. It seems that Ruby 1.9 is the Next Big Thing, and 1.8 is soon to unsupported, so a number of distros are moving to it as the default. I've spent the evening digging into what it would take to support Ruby 1.9, but my Ruby-fu is so weak that it'll be more than an evening for me to actually make progress on the issue. I invite more capable hands to join in the effort. -Hyrum
Re: [svnbench] Revision: 1389172 compiled Sep 24 2012, 00:21:39 on x86_64-unknown-linux-gnu
On Mon, Sep 24, 2012 at 7:26 PM, Ivan Zhakov i...@visualsvn.com wrote: On Mon, Sep 24, 2012 at 10:03 PM, Stefan Sperling s...@elego.de wrote: On Mon, Sep 24, 2012 at 01:50:36PM -0400, C. Michael Pilato wrote: That's correct. And Philip, I see this as really two issues: 1. we auto-upgrade working copies (at all) 2. we auto-upgrade working copies that are arguably not the true targets of an operation. I can live with the first problem if I must. It's the second that's the more egregious of the two, in my book. So yes, I think it makes (as you suggested elsethread) to add a 'read-only' mode to the WCDB, and to use that mode in the initial exploratory phases of a checkout operation. Maybe we provide a way to upgrade that to read/write programmatically rather than closing and re-opening the DB ... no opinion there. Whatever makes the most sense. Or we just disable auto-upgrade. I think we've seen enough reasons now why it's just a plain stupid idea in practice. +1 to disable auto-upgrade. WC upgrade is non reversible operation and performing it silently is very bad idea. Yet again I give my hearty +1 (and wonder why this is still even a question several months after first discussing the issue. :/ ) -Hyrum
Re: buildbot failure in ASF Buildbot on svn-x64-ubuntu-gcc
On Mon, Sep 24, 2012 at 7:38 PM, Hyrum K Wright hy...@hyrumwright.org wrote: The svn-x64-ubuntu-gcc bot currently lives in my basement, and was recently upgraded to the latest Ubuntu beta release, which bumped a number of dependency versions. The biggest issue with the bindings is the bump to Ruby 1.9 which we explicitly don't support because the tests are not currently compatible with it. It seems that Ruby 1.9 is the Next Big Thing, and 1.8 is soon to unsupported, so a number of distros are moving to it as the default. I've spent the evening digging into what it would take to support Ruby 1.9, but my Ruby-fu is so weak that it'll be more than an evening for me to actually make progress on the issue. I invite more capable hands to join in the effort. Yeah I noticed the Ruby failure. If the machine running this buildbot is being shared by some other use for you maybe we should split this off. I have a KVM setup dedicated for Subversion work and would be happy to host this slave as a dedicated guest. This would allow us to have upgrades only when we wanted them for the specific build slave. Obviously the work to move to 1.9 would still need to be done, but there's really not much value in having our build bot fail on something we're not expecting to work.
Re: buildbot failure in ASF Buildbot on svn-x64-ubuntu-gcc
On Mon, Sep 24, 2012 at 11:15 PM, Ben Reser b...@reser.org wrote: On Mon, Sep 24, 2012 at 7:38 PM, Hyrum K Wright hy...@hyrumwright.org wrote: The svn-x64-ubuntu-gcc bot currently lives in my basement, and was recently upgraded to the latest Ubuntu beta release, which bumped a number of dependency versions. The biggest issue with the bindings is the bump to Ruby 1.9 which we explicitly don't support because the tests are not currently compatible with it. It seems that Ruby 1.9 is the Next Big Thing, and 1.8 is soon to unsupported, so a number of distros are moving to it as the default. I've spent the evening digging into what it would take to support Ruby 1.9, but my Ruby-fu is so weak that it'll be more than an evening for me to actually make progress on the issue. I invite more capable hands to join in the effort. Yeah I noticed the Ruby failure. If the machine running this buildbot is being shared by some other use for you maybe we should split this off. I have a KVM setup dedicated for Subversion work and would be happy to host this slave as a dedicated guest. This would allow us to have upgrades only when we wanted them for the specific build slave. Obviously the work to move to 1.9 would still need to be done, but there's really not much value in having our build bot fail on something we're not expecting to work. For the time being, the Ruby build step and tests have been commented out of the relevant scripts. I think there is value in running a bot on a stock (albeit currently beta) install of a popular Linux distribution. We don't control our users' machines, and pretty soon many of them will be upgrading to the latest Ubuntu. A not-insignificant-number of those people will discover their Subversion Ruby scripts don't work anymore. This is unfortunate, and the sooner we can find these problems, the better. Running a bot in this type of environment is one way to do so. (Plus, I haven't committed a line of code in 3 months: I have to do _something_ to feel more useful than just kibitzing on dev@. :) ) You are, of course, welcome to run yet another bot with its own configuration, but I recommend we still use this one. -Hyrum
Re: buildbot failure in ASF Buildbot on svn-x64-ubuntu-gcc
On Mon, Sep 24, 2012 at 8:27 PM, Hyrum K Wright hy...@hyrumwright.org wrote: For the time being, the Ruby build step and tests have been commented out of the relevant scripts. I think there is value in running a bot on a stock (albeit currently beta) install of a popular Linux distribution. We don't control our users' machines, and pretty soon many of them will be upgrading to the latest Ubuntu. A not-insignificant-number of those people will discover their Subversion Ruby scripts don't work anymore. This is unfortunate, and the sooner we can find these problems, the better. Running a bot in this type of environment is one way to do so. (Plus, I haven't committed a line of code in 3 months: I have to do _something_ to feel more useful than just kibitzing on dev@. :) ) You are, of course, welcome to run yet another bot with its own configuration, but I recommend we still use this one. Well I agree there's value in that configuration, since as you rightly point out it does alert us to upcoming issues. Coming from a continuous delivery workplace here recently I was thinking that the primary purpose of the buildbots was to alert us to breakage after code changes. If the environment the build bot is running in is changing out from under it, you can't tell at a glance that the build was broken due to a code change or an environmental change on the build bot.
Re: Apache Subversion Wiki
Just registered, many thanks. On 24 September 2012 14:24, Stefan Sperling s...@elego.de wrote: On Sat, Sep 22, 2012 at 01:59:43AM +0100, Ethan Cane wrote: Hi there, Is it possible I could receive editing rights on the Apache Subversion Wiki. I'd like very much to make contributions and support the Subversion software project. If permitted then a username of 'EthanCane' would prove ideal. Regards Ethan Cane http://svnmate.com/ Hi Ethan, please register an account with the wiki on this page: http://wiki.apache.org/subversion/ContributorsGroup?action=newaccount I'll then grant your account the necessary editing permissions. Looking forward to your contributions. Thanks!
