RE: Assertion error
Looks like my subversion config file is as delivered i.e. all comments. I probably forgot to update it when I got a new machine. So I guess that means the setting is at the default. I've also got that thing where on UNIX you get those extra ^M in the file which I guess is all related. We have a standard file of settings which I will apply now. Thanks for all your replies btw. Si -Original Message- From: Nathan Hartman Sent: 09 November 2020 23:39 To: Daniel Shahaf Cc: Simon Heffer ; dev@subversion.apache.org Subject: Re: Assertion error On Mon, Nov 9, 2020 at 4:47 PM Daniel Shahaf wrote: > > Nathan Hartman wrote on Mon, 09 Nov 2020 15:49 -0500: > > On Mon, Nov 9, 2020 at 1:55 PM Simon Heffer > > wrote: > > > > > > HI Nathan, > > > > > > In my content. Not sure why J > > > > That could happen when users from multiple OSes interact with the > > same files. Also, it could happen if you copy-and-paste text from a > > file with a different EOL style, if your editor does not > > automatically convert EOLs upon pasting. > > To be clear, it's an assertion error, so it shouldn't happen, period, > even in the cases mentioned, and the fact that it does happen > constitutes a bug. Agreed. I'm trying to narrow down the search for it, e.g., is it in eol-style processing, etc. Nathan
RE: Assertion error
HI Nathan, In my content. Not sure why ☺ Si From: Nathan Hartman Sent: 09 November 2020 18:53 To: Simon Heffer Cc: dev@subversion.apache.org Subject: Re: Assertion error On Mon, Nov 9, 2020 at 12:43 PM Simon Heffer mailto:simon.hef...@microfocus.com>> wrote: Thanks Andreas , looks like it wasn't coping with mixed EOLs, it was fine once I fixed them. Where were the mixed EOLs, in your content or in the log message? Thanks, Nathan
RE: Assertion error
Thanks Andreas , looks like it wasn't coping with mixed EOLs, it was fine once I fixed them. Si -Original Message- From: Andreas Stieger Sent: 09 November 2020 17:16 To: Simon Heffer ; dev@subversion.apache.org Subject: Re: Assertion error Hello Simon, On 11/9/20 10:17 AM, Simon Heffer wrote: > TortoiseSVN 1.11.1, Build 28492 - 64 Bit , 2019/01/08 21:40:39 Upgrade to 1.14.0 and try again. Andreas
Assertion error
Hi Chaps, I got this error committing on windows using tortoise svn (which is now hung): [cid:image001.png@01D6B678.7F6DA070] Versiopn info: TortoiseSVN 1.11.1, Build 28492 - 64 Bit , 2019/01/08 21:40:39 ipv6 enabled Subversion 1.11.1, -release apr 1.6.5 apr-util 1.6.1 serf 1.3.9 OpenSSL 1.1.0j 20 Nov 2018 zlib 1.2.11 SQLite 3.23.1 Simon Heffer Simon Heffer Installation & Licensing Team Micro Focus simon.hef...@microfocus.com<mailto:simon.hef...@microfocus.com> The Lawn, 22-30 Old Bath Road Newbury Berkshire RG14 1QN United Kingdom Direct: +44 1635 565629
Re: Subversion's community health
An interesting if slightly sad read. I want to add my support and praise
as a long-time user of Subversion.
I still come across many users out there. Subversion is thriving in one
particular business I work with. The youngsters have brought some Git in
with them but it seems to be led by fashion than anything else.
Subversion remains.
I choose Subversion over all other options for my own personal projects.
I like the simplicity and clarity.
I was recently considering some git-svn monster to allow local branching
on a big Subversion-hosted project but then I discovered the svn
shelving experiments. The checkpointing addition changes everything. I
cannot overstate that. I feel it's important to fully release
shelving/checkpointing and publicise the shift that it brings to working
with Subversion.
Of course, none of this magically brings new developers to the project
but perhaps it will provide motivation.
S.
On 2019/06/14 13:26:41, Julian Foad wrote:
> The Subversion community has gradually become much less active. We
have >
> reached the point where we are struggling to even put out a release.>
>
> Johan said I may quote his thoughts, so I will:>
> > Indeed, I was just wondering about the same thing, before I read
your>
> > response, Julian. It's quite clear that things are getting more and>
> > more quiet . I feel the project is slowly dying ...>
> > >
> > Sometimes I try to give an issue a little push by summarizing it on>
> > the dev list, or by giving some ideas, but for me that's usually
about>
> > all I can do (limited time, limited knowledge, ...). I'm not the
only>
> > one of course. Sometimes, others give a little push as well, and
with>
> > enough hands some things still get done. But lately, those little>
> > pushes seem to become more and more rare.>
> > >
> > Also: if Julian's funding stops, will we get another release out?>
> > Theoretically we can, of course, but will we?>
> > >
> > I'm not blaming anyone of course. We're all volunteers, time gets>
> > consumed by other things, motivations and priorities shift, ... But
it>
> > makes me a little sad .>
> > >
> > Can we do something about it? Or is this just the way it is ... a>
> > normal project lifecycle of which we've reached the end? It's
become>
> > old and un-sexy legacy software ... at least in the perception of
the>
> > masses. Can we revive it, or give it a second life?>
> > >
> > .oO("Make Subversion sexy again" :-))>
>
> Is this a Bad Thing? It is not objectively bad that the development
has >
> tailed off; that's simply what happens when a project moves on to its
>
> "mature" stage in its life cycle. But it is causing some problems in >
> adapting to the "new normal".>
>
> We have reached the point where we are struggling to even put out a >
> release because not enough developers are volunteering to do the work
>
> required. (A release, no matter how minor the changes, currently >
> requires reviewing, testing, voting, writing release notes, updating >
> other web pages, and so on. Some of the steps are mostly automated but
>
> others are not.)>
>
> So, we might want to look at changing how we do releases. I have some
>
> other thoughts too. But first, I'd like to invite others to speak up.>
>
> Anyone with constructive suggestions, please do share them. Please let
>
> us not dwell on our sadness and criticism of what went before; let us
>
> try to keep this thread focused on positive solutions for what to do
next.>
>
> - Julian>
>
>
Bug in lib_ra_serf ssl_server_cert()
We have found a bug in the ssl_server_cert() function in lib_ra_serf. This bug is present in 1.8.14 but we believe it has been present for some time. The bug is as follows: If Serf determines that a server certificate is invalid it calls into lib_ra_serf, which then requests two types of credentials from the authentication stack: SVN_AUTH_CRED_SSL_SERVER_AUTHORITY (this appears to be only relevant on Windows) and SVN_AUTH_CRED_SSL_SERVER_TRUST. Calls to svn_auth_first_credentials(), svn_auth_next_credentials() and svn_auth_save_credentials() are preceded by calls to svn_auth_set_parameter() to set values for the SVN_AUTH_PARAM_SSL_SERVER_FAILURES and SVN_AUTH_PARAM_SSL_SERVER_CERT_INFO parameters (lines 371, 375, 418 and 422). Significantly, both of these parameters are set to the address of stack variables. Both parameters are reset (i.e. removed) after the call to svn_auth_first_credentials() for SVN_AUTH_CRED_SSL_SERVER_AUTHORITY (lines 388 and 391). However, SVN_AUTH_PARAM_SSL_SERVER_FAILURES is *not* removed after requesting credentials of type SVN_AUTH_CRED_SSL_SERVER_TRUST (line 428) even though SVN_AUTH_PARAM_SSL_SERVER_CERT_INFO is (line 452). As a result, the auth_baton’s parameter set is left with a value that points to a stack variable when the function ends. If this value is dereferenced at a later time (for example when responding to a request for another credential type such as SVN_AUTH_CRED_SIMPLE) then either the address is invalid and the application segfaults or garbage is read from the stack. Proposed solution: SVN_AUTH_PARAM_SSL_SERVER_FAILURES should be removed from the auth_baton’s parameters before ssl_server_cert() returns. This is already the case for SVN_AUTH_PARAM_SSL_SERVER_CERT_INFO. As an aside: The practice of temporarily setting pointers to stack variables as the values of auth_baton parameters seems questionable. This issue would have resulted in a benign, out-of-date parameter if the value for SVN_AUTH_PARAM_SSL_SERVER_FAILURES had been allocated from the appropriate pool rather than the stack. Also: One might question why an application needs to inspect the value of SVN_AUTH_PARAM_SSL_SERVER_FAILURES outside of the scope of a request for SVN_AUTH_CRED_SSL_SERVER_AUTHORITY or SVN_AUTH_CRED_SSL_SERVER_TRUST credentials. In our case, the application is written in a higher-level language than C (Objective-C) and calls to our authentication providers pass through a C -> Obj-C bridge layer. As a result, the sets of parameters passed to our callback functions are converted into Obj-C dictionaries in their entirety. It was this conversion of invalid SVN_AUTH_PARAM_SSL_SERVER_FAILURES values that caused segfaults in our application. Best regards, Simon Wilson smime.p7s Description: S/MIME cryptographic signature
Re: Bug in lib_ra_serf ssl_server_cert()
Hi Bert, > But given this and our documentation, the only thing about the passed hash > that we promise are that for each callback type only specific keys are valid > in the hashtable. All the other values are undefined and it is really upt o > the api user on how that affects them. In general it should only use the > defined values and ignore the rest. This is true to a point. If lib_ra_serf was writing the parameters to an apr_hash_t that was private to the call stack (and therefore specific to the calling context) then I would concur. However, lib_ra_serf uses svn_auth_set_parameter() to set *global* parameters for the auth_baton. As such, these parameters are published to the entire application: any other code might reasonably expect to be able to read these values (e.g. for debugging/diagnostics) at any time without crashing due to invalid pointers. They are also left as garbage in plain sight for any subsequent callback to any auth provider. This is just bad hygiene — lib_ra_serf should be able to clean up after itself! > If you are reading those other pointer values, there is no way you could know > what they point to (They are just void*) and are undefined/may change. We’re not trying to extract the values for all the parameters in the hash, just the standard set of parameters defined in svn_auth.h (where the types are clearly defined). The rest are indeed ignored. We have implemented two workarounds at our end: as a short-term fix we will only extract SVN_AUTH_PARAM_SSL_SERVER_FAILURES for callbacks requesting SVN_AUTH_CRED_SSL_SERVER_TRUST creds. We have also implemented a long-term fix where we extract properties from the hash upon request from the auth provider rather than converting all parameters up front. I posted about the fix as a courtesy to the svn devs. It would be great if you could fix it, but we’re not dependent on it at our end. Many thanks and best regards, Simon > On 18 Sep 2015, at 15:31 pm, b...@qqmail.nl wrote: > > The problem here is two folded: > I agree that we *should* properly remove these items from the hash, but we > have had the current behavior since 1.0 even in our previous dav > implementation. > > But given this and our documentation, the only thing about the passed hash > that we promise are that for each callback type only specific keys are valid > in the hashtable. All the other values are undefined and it is really upt o > the api user on how that affects them. In general it should only use the > defined values and ignore the rest. > > If you are reading those other pointer values, there is no way you could know > what they point to (They are just void*) and are undefined/may change. Your > implementation should be careful not to just resolve these value and use the > values for something. (We are free to store (void*)1 as marker or use > undefined structure types, as we do in many other places). > > I’m happy to apply a patch that fixes the first problem, but I don’t see a > valid way to crash a valid usage of this api. Causing a segfault based on > this problem relies on using undefined behavior somewhere. > (That’s why I didn’t direcly fix it when I noticed this same problem a few > years ago... That and that I couldn’t think of a simple patch to easily fix > this. Things might be easier today after recent refactorings) > >Bert > > > From: Simon Wilson > Sent: vrijdag 18 september 2015 15:05 > To: dev@subversion.apache.org > Subject: Bug in lib_ra_serf ssl_server_cert() > > > We have found a bug in the ssl_server_cert() function in lib_ra_serf. This > bug is present in 1.8.14 but we believe it has been present for some time. > > The bug is as follows: > > If Serf determines that a server certificate is invalid it calls into > lib_ra_serf, which then requests two types of credentials from the > authentication stack: SVN_AUTH_CRED_SSL_SERVER_AUTHORITY (this appears to be > only relevant on Windows) and SVN_AUTH_CRED_SSL_SERVER_TRUST. > > Calls to svn_auth_first_credentials(), svn_auth_next_credentials() and > svn_auth_save_credentials() are preceded by calls to svn_auth_set_parameter() > to set values for the SVN_AUTH_PARAM_SSL_SERVER_FAILURES and > SVN_AUTH_PARAM_SSL_SERVER_CERT_INFO parameters (lines 371, 375, 418 and 422). > Significantly, both of these parameters are set to the address of stack > variables. > > Both parameters are reset (i.e. removed) after the call to > svn_auth_first_credentials() for SVN_AUTH_CRED_SSL_SERVER_AUTHORITY (lines > 388 and 391). However, SVN_AUTH_PARAM_SSL_SERVER_FAILURES is *not* removed > after requesting credentials of type SVN_AUTH_CRED_SSL_SERVER_TRUST (line > 428) even though SVN_AUTH_PARAM_SSL_SERVER_CERT_INFO is (line 452). > > As
Cannot checkout or update from svnserve 1.6
Hi guys, I have the TortoiseSVN build of the command line client, built against r1451811. I'm trying to update an upgraded 1.7 working copy from a repository served by svnserve 1.6.11 Update from the repo root works OK, update from lower down in the tree fails with: svn up Updating '.': svn: E210001: Unknown command 'get-iprops' I thought it might be a problem with the WC upgrade so I tried a fresh checkout and got the same error. Server is running on Windows SBS 2003 Client is running on Windows 7 If you need access to the test repo I used I can give it via PM. Simon -- : ___ : oo // \\ De Chelonian Mobile : (_,\/ \_/ \ TortoiseSVN : \ \_/_\_/The coolest Interface to (Sub)Version Control : /_/ \_\ http://tortoisesvn.net
Re: why does tortoise, wcng and cygwin break from icon caching?
On 6 July 2012 09:04, Stefan Fuhrmann stefan.fuhrm...@wandisco.com wrote: On Fri, Jul 6, 2012 at 12:58 AM, Neels J Hofmeyr ne...@elego.de wrote: Today Random Person on #svn reported a problem and later its apparent solution, and it struck me as rather peculiar: [[[ yates` when trying to do an svn cleanup, i get a strange message: svn: E200030: disk I/O error, executing statement 'COMMIT TRANSACTION;' I suspect a reader / writer locking issue with Sqlite. The I/O error as such might be related to the win7 / cygwin combination requiring more retries or such. this is under win7 using the cygwin svn client and also tortoisesvn is installed ... yates` neels: i found the issue strangely, there is an interaction between tortoisesvn and the cli svn under cygwin you must disable tortoisesvn's icon caching, then the problem goes away. http://www.mail-archive.com/cygwin@cygwin.com/msg123745.html ]]] I.e. they disabled the background process that will open the working copy soon after the OS detected some file change. The scan itself may take a very long time. Depending on OS and wc details, the db may get opened at some very inconvenient time while the commit is still in progress / in some critical stage. and I've confirmed what others have stated that it's only a problem with v3.7.12.1 and NOT a problem with v3.7.3. Hmm, disable icon caching to not break wc-ng? Why!? I think to remember that access to WCNG is much more exclusive than it used to be in 1.6. But I don't know whether that is actually true not the details. In our FAQ we advise against using TortoiseSVN with CygWin because Subversion was never designed to share a working copy between Windows and *nix clients. I thought this was in the SVN FAQ too, but can't find it right now. http://tortoisesvn.net/faq.html#multiclients Simon -- : ___ : oo // \\ De Chelonian Mobile : (_,\/ \_/ \ TortoiseSVN : \ \_/_\_/The coolest Interface to (Sub)Version Control : /_/ \_\ http://tortoisesvn.net
Re: AW: SQLite locking for WCNG on NFS
On Wed, Feb 22, 2012 at 1:25 AM, Philip Martin philip.mar...@wandisco.comwrote: Branko Čibej br...@apache.org writes: On 20.02.2012 09:51, Markus Schaber wrote: Hi, What about an -exclusive general option to the svn command line client, which triggers exclusive wc access for that specific command invocation / session? And you expect users to know when to use it, and especially when /not/ to use it? Come now. Controlling performance tweaks from the user interface is hardly good design. Not sure I agree, I don't see how anything other than the user can make the choice. The user has more information than the application can ever have. If the user wants to be able to run two subtree updates in parallel then exlusive locking must not be enabled. If the user wants to run status during an update then exclusive locking must not be enabled. If the user is happy with one process having exclusive access then exclusive locking is a major performance gain. If the user isn't making that decision how else can it be made? The performance gains on NFS are large. I import Subversion trunk into a repository to use as my dataset. I checkout, run status, modify a single file, commit, run update. This is on my Linux-Linux NFS setup, which isn't fast but has no other users. without with exclusive exclusive checkout: 2m33s 53s status cold: 3.6s 1.3s status hot: 2.6s 0.4s commit: 35s3s update: 4s0.9s It's hard to ignore performance gains that are so big. We could completely rewrite the commit harvester to use queries more suited to the single db. That might be faster but I don't know whether it would it would get us the order of magnitude gain that exclusive locking provides. It's a non-trivial amount of code. I suppose we might be able to make status into a single query, but like commit that's a major bit of code to be rewritten. It's certainly not going to happen in 1.7, I suppose it might happen in 1.8. We would also prefer exclusive locking in our workflow and it would be great if we could program-in this kind of optimization in the client. I'm guessing there will others like this so why not have an optimize of similar switch that can take a list of settings (including exclusive=t)?
Re: SQLite locking for WCNG on NFS
Could you fold this into the main code as an option? No one seems to talk about some of the significant performance issues with SVN 1.7 much here. For many people SVN 1.7 is still not an option due to these kinds of performance issues. It seems like we need to revisit many the SQLite operations used.
Re: [Patch] get-deps.sh fails to find sqlite-amalgamation
On 23 Jun 2011, at 17:32, Daniel Shahaf wrote: when trying to build SVN 1.6 from this branch: http://svn.apache.org/repos/asf/subversion/branches/1.6.x get-deps.sh fails, because sqlite-amalgamation has been moved: --2011-06-23 14:47:38-- http://www.sqlite.org/sqlite-amalgamation-3.7.5.tar.gz Resolving www.sqlite.org... 67.18.92.124 Connecting to www.sqlite.org|67.18.92.124|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-06-23 14:47:39 ERROR 404: Not Found. I fixed this by using the get-deps.sh script from trunk (with corrected versions of course). Should I create an issue? No, please re-send the patch as a *.txt attachment. Attached is the patch. Regards Simon Index: get-deps.sh === --- get-deps.sh (revision 1138852) +++ get-deps.sh (working copy) @@ -29,7 +29,7 @@ SERF=serf-0.7.0 ZLIB=zlib-1.2.5 SQLITE_VERSION=3.7.5 -SQLITE=sqlite-amalgamation-$SQLITE_VERSION +SQLITE=sqlite-amalgamation-$(printf %u%02u%02u%02u $(echo $SQLITE_VERSION | sed -e s/\./ /g)) HTTPD=httpd-2.2.18 APR_ICONV=apr-iconv-1.2.1 @@ -50,18 +50,18 @@ wget -nc http://webdav.org/neon/$NEON.tar.gz wget -nc http://serf.googlecode.com/files/$SERF.tar.bz2 wget -nc http://www.zlib.net/$ZLIB.tar.bz2 -wget -nc http://www.sqlite.org/$SQLITE.tar.gz +wget -nc http://www.sqlite.org/$SQLITE.zip cd $BASEDIR gzip -dc $TEMPDIR/$NEON.tar.gz | tar -xf - bzip2 -dc $TEMPDIR/$ZLIB.tar.bz2 | tar -xf - bzip2 -dc $TEMPDIR/$SERF.tar.bz2 | tar -xf - -gzip -dc $TEMPDIR/$SQLITE.tar.gz | tar -xf - +unzip -q $TEMPDIR/$SQLITE.zip mv $NEON neon mv $ZLIB zlib mv $SERF serf -mv sqlite-$SQLITE_VERSION sqlite-amalgamation +mv $SQLITE sqlite-amalgamation bzip2 -dc $TEMPDIR/$APR.tar.bz2 | tar -xf - bzip2 -dc $TEMPDIR/$APR_UTIL.tar.bz2 | tar -xf -
Re: [Patch] get-deps.sh fails to find sqlite-amalgamation
On 23 Jun 2011, at 19:00, Daniel Shahaf wrote: This is a part of r1134734. Backport proposed. Thanks! Great, thanks Daniel. Simon
svn delete fails when deleting multiple URLs with URL-encoded spaces
I'm posting here for feedback before opening an issue with the Subversion tracker. Passing multiple URLs to 'svn delete' generates the following error when one or more of the URLs contains a URL-encoded space (i.e. %20): URL 'file:///Users/me/dev/repo/lib/tags/2.0.3.008%2520(R2.0.3)' does not exist The error has status 160013 and originates at subversion/libsvn_client/delete.c, 197 The actual URL specified to 'svn delete' was 'file:///Users/me/dev/repo/lib/tags/2.0.3.008%20(R2.0.3)', i.e. the name of the directory being deleted is '2.0.3.008 (R2.0.3)'. The error description indicates that 'svn delete' is double-encoding the URL, incorrectly replacing the '%' character from the URL-encoded space (i.e. %20) with %25, resulting in an incorrect URL. Specifying a single URL with a URL-encoded space to 'svn delete' works as expected. A cursory glance at the source for svn_client_delete3 and svn_path_condense_targets indicates that svn_path_condense_targets contains special-case handling for a single URL. This might explain why the double-encoding is not encountered when a single URL is specified to 'svn delete' and may indicate that svn_path_condense_targets is the source of the error. Other observations: * This appears to be a regression. I could not reproduce this error with 'svn' on the command line for the build of 1.6.5 included with Mac OS X 10.6.6. I also could not reproduce this when using the svn_client_delete2 API with a 1.6.6 static library we built from source. * This behavior seems to have been introduced at some point between 1.6.7 and 1.6.12. We have verified that the bug exists in 1.6.12 and is still in evidence in 1.6.16. We have not tested 1.6.7 - 1.6.11 explicitly. * This may not seem to be a particularly severe issue to users of the 'svn' command-line interface. However, we use the svn_client_delete2 API in our Mac svn product to allow the user to delete the selected files in a browser GUI which supports multiple selection. This makes it trivial for the user to delete multiple items from a repository in a single commit, and greatly increases the likelihood of users experiencing this issue. Best regards, Simon Wilson http://www.zennaware.com
Re: svn delete fails when deleting multiple URLs with URL-encoded spaces
I have created issue #3839. Best regards, Simon http://www.zennaware.com On Mar 17, 2011, at 12:36 PM, Stefan Sperling wrote: On Thu, Mar 17, 2011 at 12:19:01PM +0100, Simon Wilson wrote: I'm posting here for feedback before opening an issue with the Subversion tracker. Please feel free to file an issue. Thank you! Passing multiple URLs to 'svn delete' generates the following error when one or more of the URLs contains a URL-encoded space (i.e. %20): URL 'file:///Users/me/dev/repo/lib/tags/2.0.3.008%2520(R2.0.3)' does not exist The error has status 160013 and originates at subversion/libsvn_client/delete.c, 197 The actual URL specified to 'svn delete' was 'file:///Users/me/dev/repo/lib/tags/2.0.3.008%20(R2.0.3)', i.e. the name of the directory being deleted is '2.0.3.008 (R2.0.3)'. The error description indicates that 'svn delete' is double-encoding the URL, incorrectly replacing the '%' character from the URL-encoded space (i.e. %20) with %25, resulting in an incorrect URL. Specifying a single URL with a URL-encoded space to 'svn delete' works as expected. A cursory glance at the source for svn_client_delete3 and svn_path_condense_targets indicates that svn_path_condense_targets contains special-case handling for a single URL. This might explain why the double-encoding is not encountered when a single URL is specified to 'svn delete' and may indicate that svn_path_condense_targets is the source of the error. Other observations: * This appears to be a regression. I could not reproduce this error with 'svn' on the command line for the build of 1.6.5 included with Mac OS X 10.6.6. I also could not reproduce this when using the svn_client_delete2 API with a 1.6.6 static library we built from source. * This behavior seems to have been introduced at some point between 1.6.7 and 1.6.12. We have verified that the bug exists in 1.6.12 and is still in evidence in 1.6.16. We have not tested 1.6.7 - 1.6.11 explicitly. * This may not seem to be a particularly severe issue to users of the 'svn' command-line interface. However, we use the svn_client_delete2 API in our Mac svn product to allow the user to delete the selected files in a browser GUI which supports multiple selection. This makes it trivial for the user to delete multiple items from a repository in a single commit, and greatly increases the likelihood of users experiencing this issue. Best regards, Simon Wilson http://www.zennaware.com
Re: 64-bit Subversion crashes on Mac OS X
I'm posting here for feedback before opening an issue with Subversion tracker. Using the 'svn mkdir' command against a 1.5/1.6 format repository via ra_local (i.e. with a file:// URL) with 64-bit Subversion on Mac OS X results in a segmentation fault. This 100% reproducible both with 'svn' in Terminal and when loaded as a library in our Cocoa application. Please file an issue. Thanks! Done: http://subversion.tigris.org/issues/show_bug.cgi?id=3829
Re: 64-bit Subversion crashes on Mac OS X
On Mon, Mar 07, 2011 at 08:59:35AM +0100, Simon Wilson wrote: I'm posting here for feedback before opening an issue with Subversion tracker. Using the 'svn mkdir' command against a 1.5/1.6 format repository via ra_local (i.e. with a file:// URL) with 64-bit Subversion on Mac OS X results in a segmentation fault. This 100% reproducible both with 'svn' in Terminal and when loaded as a library in our Cocoa application. Please file an issue. Thanks! Is this http://mid.gmane.org/56ce4fbf-08c1-456e-a475-ce65d17e0...@barrys-emacs.org ? I have no idea whether this is related to the crash we're experiencing, but have filed an issue (http://subversion.tigris.org/issues/show_bug.cgi?id=3829). I have added the link you posted as a comment. Simon
64-bit Subversion crashes on Mac OS X
I'm posting here for feedback before opening an issue with Subversion tracker. Using the 'svn mkdir' command against a 1.5/1.6 format repository via ra_local (i.e. with a file:// URL) with 64-bit Subversion on Mac OS X results in a segmentation fault. This 100% reproducible both with 'svn' in Terminal and when loaded as a library in our Cocoa application. We first detected this behavior in 1.6.14. We are building against the Mac OS X 10.5 SDK. We build 3-way universal libraries for Subversion (x86, ppc and X86_64). We have only seen this crash in the 64-bit Intel version running on Mac OS X 10.6 Snow Leopard. Here is relevant portion of the backtrace generated with gdb: #0 0x7fff881d1160 in strlen () #1 0x0001147a0bff in apr_vformatter () #2 0x0001147adeda in apr_pvsprintf () #3 0x0001147ae1c8 in apr_psprintf () #4 0x0001146587f0 in representation_string () #5 0x000114658a2d in svn_fs_fs__write_noderev () #6 0x000114658de2 in svn_fs_fs__put_node_revision () #7 0x00011465d0a3 in create_new_txn_noderev_from_rev () #8 0x00011465d81b in svn_fs_fs__create_txn () #9 0x000114663c09 in svn_fs_fs__begin_txn () #10 0x00011466fda3 in svn_fs_begin_txn2 () #11 0x0001146a5613 in svn_repos_fs_begin_txn_for_commit2 () #12 0x0001146a19bd in open_root () #13 0x000114643e5c in svn_delta_path_driver () #14 0x000114603e42 in mkdir_urls () #15 0x000114604017 in svn_client_mkdir3 () #16 0x000114613a33 in svn_client_mkdir2 () The URL passed to svn_client_mkdir2() is: file:///Users/me/Dev/Test%20Data/Repositories/fsfs-1.5/test Here are the gcc arguments used to build the 64-bit version: gcc \ -DDARWIN \ -DSIGPROCMASK_SETS_THREAD_MASK \ -no-cpp-precomp \ -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch x86_64 \ -I./subversion/include \ -I./subversion \ -I~/Subversion/1.6.16/source/x86_64/apr/include \ -I~/Subversion/1.6.16/source/x86_64/apr-util/include \ -I~/Subversion/1.6.16/source/x86_64/neon/src \ -I~/Subversion/1.6.16/build/x86_64/include/neon \ -I~/Subversion/1.6.16/source/x86_64/sqlite-amalgamation The environment/arguments passed to configure are: ARCHFLAGS=-arch x86_64 CFLAGS=-isysroot /Developer/SDKs/MacOSX10.5.sdk -arch x86_64 LDFLAGS=-Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch x86_64 MACOSX_DEPLOYMENT_TARGET=10.5 ./configure --with-ssl --with-apxs=no --disable-shared --enable-threadsafe-ssl We build against the APR and Neon versions included with the Subversion dependencies download. The GCC version used is i686-apple-darwin10-gcc-4.2.1. Best regards, Simon Wilson http://www.zennaware.com
Re: [PATCH] Add a '--fsfs-no-repsharing' flag to svnadmin
On Tue, Aug 3, 2010 at 18:20, Daniel Shahaf d...@daniel.shahaf.name wrote: Perhaps the patch would face more friendly winds if you retained the API bit, but replaced --fsfs-no-rep-sharing by some more generic --config-option flag? (compare 'svn --config-option') I think moving --fsfs-no-rep-sharing under --config-option will be inconsistent with existing options --bdb-txn-nosync and --bdb-log-keep. Besides that --config-option usually sets up environment for command execution rather than directly affects command execution result. Folks do you have any more objections to the patch prevent its applying? -- Simon Atanasyan VisualSVN Limited
Re: [PATCH] Add a '--fsfs-no-repsharing' flag to svnadmin
On Mon, Aug 2, 2010 at 23:04, Daniel Shahaf d...@daniel.shahaf.name wrote: Simon Atanasyan wrote on Mon, Aug 02, 2010 at 19:59:31 +0400: From the programmer's point of view if you create repository calling svn_fs_create with the new configuration option you easily get well commented db/fsfs.conf with necessary settings. svn_fs_create() already takes an FS_CONFIG parameter. We could populate the initially-created fsfs.conf with values from that parameter... If I understand you correctly my patch does exactly the same things. It checks file system configuration options in the write_config function (called from svn_fs_fs__create) and generates corresponded db/fsfs.conf. -- Simon Atanasyan VisualSVN Limited
Re: [PATCH] Add a '--fsfs-no-repsharing' flag to svnadmin
On Tue, Jul 20, 2010 at 20:29, Hyrum K. Wright hy...@hyrumwright.org wrote: On Jul 20, 2010, at 9:32 AM, Simon Atanasyan si...@visualsvn.com wrote: The general idea of the patch is to introduce new svnadmin option and FSFS filesystem configuration option to allow enabling/disabling repository sharing on FSFS. I am not sure that SQLite locking works correctly over network share due the limit file level locking support offered by OS for network shares. SQLite is used for repository sharing so it may lead to repository corruption. svnadmin and filesystem configuration options help users control this issue. Is this in addition or in place of the already-present capability to disable rep-sharing via the db/fsfs.conf file? Since we already expose the option elsewhere, I'm not convinced we need an additional option for svnadmin. Additionally, if the underlying filesystem doesn't support locking correctly, you've got bigger problems than SQLite behavior. :) Although I am really not sure of the correctness of SQLite on a network share and links below somewhat proof my idea the only purpose of this patch is just to provide easy way for handling CONFIG_OPTION_ENABLE_REP_SHARING option in the db/fsfs.conf. It is just a command line and programming interface for existent capability to enable/disable rep-sharing via the db/fsfs.conf file. But the new svnadmin command line option and the new filesystem configuration option help end users and programmers to setup FSFS settings. For example if you recommend an user to disable rep-sharing it is much easier and clearer to say use svnadmin --fsfs-no-repsharing than to say run svnadmin, find db/fsfs.conf, open the file, find the line, uncomment it etc). From the programmer's point of view if you create repository calling svn_fs_create with the new configuration option you easily get well commented db/fsfs.conf with necessary settings. Shortly speaking the new command line switch and the new configuration option are duplicate of existent functionality but they are useful duplicates. Here are the links from SQLite documentation mention using SQLite on a network share: http://www.sqlite.org/faq.html#q5 http://www.sqlite.org/lockingv3.html -- Simon Atanasyan VisualSVN Limited
[PATCH] Add a '--fsfs-no-repsharing' flag to svnadmin
The general idea of the patch is to introduce new svnadmin option and FSFS filesystem configuration option to allow enabling/disabling repository sharing on FSFS. I am not sure that SQLite locking works correctly over network share due the limit file level locking support offered by OS for network shares. SQLite is used for repository sharing so it may lead to repository corruption. svnadmin and filesystem configuration options help users control this issue. The log message is as follows: [[[ Add a '--fsfs-no-repsharing' flag to svnadmin to allow enable/disable repository sharing on FSFS. * subversion\svnadmin\main.c (svnadmin__fsfs_no_rep_sharing): New long option identifier. (options_table): Define '--fsfs-no-repsharing'. (cmd_table): Add '--fsfs-no-repsharing' to the list of options for 'svnadmin create'. (svnadmin_opt_state): Add member 'fsfs_no_rep_sharing'. (subcommand_create): Set the value of the 'SVN_FS_CONFIG_FSFS_REP_SHARING' config option in the 'fs_config' cache. (main): Handle the '--fsfs-no-repsharing' option. * subversion\include\svn_fs.h (SVN_FS_CONFIG_FSFS_REP_SHARING): New filesystem configuration option. * subversion\libsvn_fs_fs\fs_fs.c (write_config): Use value of 'SVN_FS_CONFIG_FSFS_REP_SHARING' config option while writing FSFS filesystem configuration file. * tools\client-side\bash_completion (_svnadmin): Add '--fsfs-no-repsharing'. ]]] The patch itself is in the attachment. -- Best regards, Simon Atanasyan VisualSVN Limited
Re: [PATCH] Add a '--fsfs-no-repsharing' flag to svnadmin
On Tue, Jul 20, 2010 at 18:32, Simon Atanasyan si...@visualsvn.com wrote:
The patch itself is in the attachment.
The missed patch file.
--
Simon Atanasyan
VisualSVN Limited
Index: subversion/svnadmin/main.c
===
--- subversion/svnadmin/main.c (revision 965818)
+++ subversion/svnadmin/main.c (working copy)
@@ -218,6 +218,7 @@
svnadmin__force_uuid,
svnadmin__fs_type,
svnadmin__parent_dir,
+svnadmin__fsfs_no_rep_sharing,
svnadmin__bdb_txn_nosync,
svnadmin__bdb_log_keep,
svnadmin__config_dir,
@@ -276,6 +277,9 @@
{parent-dir,svnadmin__parent_dir, 1,
N_(load at specified directory in repository)},
+{fsfs-no-repsharing, svnadmin__fsfs_no_rep_sharing, 0,
+ N_(disable rep-sharing in the repository [FSFS])},
+
{bdb-txn-nosync, svnadmin__bdb_txn_nosync, 0,
N_(disable fsync at transaction commit [Berkeley DB])},
@@ -340,6 +344,7 @@
(usage: svnadmin create REPOS_PATH\n\n
Create a new, empty repository at REPOS_PATH.\n),
{svnadmin__bdb_txn_nosync, svnadmin__bdb_log_keep,
+svnadmin__fsfs_no_rep_sharing,
svnadmin__config_dir, svnadmin__fs_type, svnadmin__pre_1_4_compatible,
svnadmin__pre_1_5_compatible, svnadmin__pre_1_6_compatible,
svnadmin__pre_1_7_compatible} },
@@ -505,6 +510,7 @@
svn_boolean_t use_pre_revprop_change_hook;/*
--use-pre-revprop-change-hook */
svn_boolean_t use_post_revprop_change_hook; /*
--use-post-revprop-change-hook */
svn_boolean_t quiet; /* --quiet */
+ svn_boolean_t fsfs_no_rep_sharing;/* --fsfs-no-repsharing */
svn_boolean_t bdb_txn_nosync; /* --bdb-txn-nosync */
svn_boolean_t bdb_log_keep; /* --bdb-log-keep */
svn_boolean_t clean_logs; /* --clean-logs */
@@ -556,6 +562,10 @@
apr_hash_t *config;
apr_hash_t *fs_config = apr_hash_make(pool);
+ apr_hash_set(fs_config, SVN_FS_CONFIG_FSFS_REP_SHARING,
+ APR_HASH_KEY_STRING,
+ (opt_state-fsfs_no_rep_sharing ? 0 : 1));
+
apr_hash_set(fs_config, SVN_FS_CONFIG_BDB_TXN_NOSYNC,
APR_HASH_KEY_STRING,
(opt_state-bdb_txn_nosync ? 1 : 0));
@@ -1713,6 +1723,9 @@
case svnadmin__use_post_revprop_change_hook:
opt_state.use_post_revprop_change_hook = TRUE;
break;
+ case svnadmin__fsfs_no_rep_sharing:
+opt_state.fsfs_no_rep_sharing = TRUE;
+break;
case svnadmin__bdb_txn_nosync:
opt_state.bdb_txn_nosync = TRUE;
break;
Index: subversion/include/svn_fs.h
===
--- subversion/include/svn_fs.h (revision 965818)
+++ subversion/include/svn_fs.h (working copy)
@@ -72,6 +72,7 @@
*/
#define SVN_FS_CONFIG_BDB_TXN_NOSYNCbdb-txn-nosync
#define SVN_FS_CONFIG_BDB_LOG_AUTOREMOVEbdb-log-autoremove
+#define SVN_FS_CONFIG_FSFS_REP_SHARING fsfs-rep-sharing
/* See also svn_fs_type(). */
/** @since New in 1.1. */
Index: subversion/libsvn_fs_fs/fs_fs.c
===
--- subversion/libsvn_fs_fs/fs_fs.c (revision 965818)
+++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
@@ -1135,12 +1135,40 @@
### The following parameter enables rep-sharing in the repository. It can NL
### be switched on and off at will, but for best space-saving results NL
### should be enabled consistently over the life of the repository.NL
-# CONFIG_OPTION_ENABLE_REP_SHARING = true NL
+;
-;
+ apr_file_t *fsfs_conf_file;
+ void *cfg_value = NULL;
+ const char *cfg_str;
+
+ SVN_ERR(svn_io_file_open(fsfs_conf_file,
+ svn_dirent_join(fs-path, PATH_CONFIG, pool),
+ APR_WRITE | APR_CREATE, APR_OS_DEFAULT,
+ fs-pool));
+
+ SVN_ERR(svn_io_file_write_full(fsfs_conf_file, fsfs_conf_contents,
+ strlen(fsfs_conf_contents), NULL,
+ fs-pool));
+
+ /* Get enable-rep-sharing option value from the config. */
+ if (fs-config)
+cfg_value = apr_hash_get(fs-config,
+ SVN_FS_CONFIG_FSFS_REP_SHARING,
+ APR_HASH_KEY_STRING);
+
+ /* Build enable-rep-sharing option string representation. */
+ if (cfg_value != NULL strcmp(cfg_value, 1) != 0)
+cfg_str = CONFIG_OPTION_ENABLE_REP_SHARING = false NL;
+ else
+cfg_str = # CONFIG_OPTION_ENABLE_REP_SHARING = true NL;
+
+ /* Write enable-rep-sharing option to the config file. */
+ SVN_ERR(svn_io_file_write_full(fsfs_conf_file,
+ cfg_str, strlen(cfg_str),
+ NULL, fs-pool));
+
#undef NL
- return svn_io_file_create(svn_dirent_join(fs-path, PATH_CONFIG, pool
Re: DeltaV, which has been ripped out...
Thanks Mark, I feel much happer now I understand a bit more. Nothing was droppd. The SVN client is just going to have a more efficient conversation with the server via HTTP when both client and server are running 1.7. Is there any documentation on the simpler interface or is it still very much in flux? Note that SVN has never truly supported DeltaV though, so a generic DeltaV SVN client may or may not work. Yep, I have a Generic WebDAV client into which I shall graft just enough DeltaV to allow a few simple SVN operations. It sounds like it was obsolete before you started :) Mmm... I shall not rise to the bait, I am strong... Thanks for the answers, Its difficult to catch up with the SVN backstory starting from nothing.. -Steve
