Re: Crash during attempted dump of repository
On Tue, Dec 13, 2011 at 20:29, Mourrat, David (CA-CIB) wrote: > Hi all, > > I was trying to dump my repository with these results: > > E:\VoloxTmp>"C:\Program Files\VisualSVN Server\bin\svnadmin" dump -r > 19000:29950 E:\svn_repository_new > E:\VoloxTmp\dump_new.svndump > According to dump files svnadmin crashes in svn_fs_fs__id_copy in attempt to copy NULL id: libsvn_fs_fs\id.c:224: [[[ id_private_t *pvt = id->fsap_data; ]]] Here is detailed stack trace: libsvn_fs-1.dll!svn_fs_fs__id_copy( const svn_fs_id_t * id=0x, apr_pool_t * pool=0x00f720c0) Line 226 + 0xc bytes libsvn_fs-1.dll!dir_entry_id_from_node( const svn_fs_id_t * * id_p=0x0012f650, dag_node_t * parent=0x00f736c0, const char * name=0x00f735d0, apr_pool_t * pool=0x00f720c0) Line 318 + 0x12 bytes libsvn_fs-1.dll!svn_fs_fs__dag_open( dag_node_t * * child_p=0x0012f678, dag_node_t * parent=0x00f733e0, const char * name=0x00f735d0, apr_pool_t * pool=0x00f720c0) Line 1145 + 0x19 bytes libsvn_fs-1.dll!open_path( parent_path_t * * parent_path_p=0x0012f6c8, svn_fs_root_t * root=0x00c1e7a0, const char * path=0x00f72240, int flags=0x, const char * txn_id=0x, apr_pool_t * pool=0x00f720c0) Line 645 + 0x11 bytes libsvn_fs-1.dll!fs_node_proplist( apr_hash_t * * table_p=0x0012f6c8, svn_fs_root_t * root=0x00c1e7a0, const char * path=0x00f72240, apr_pool_t * pool=0x) Line 1010 + 0x44 bytes -- Ivan Zhakov
Apache Subversion 1.7.3 Released
I'm happy to announce the release of Apache Subversion 1.7.3. This release is the best available release of Subversion, and we encourage all users to upgrade as soon as practical. Subversion 1.7.3 fixes a number of crashes and improves error handling in several cases (please see CHANGES for details). This release also includes a correctness for for mod_dav_svn responses. Unfortunately, this same fix highlights several bugs already existant in svnrdump when it is run over ra_serf. For this reason, we continue to recommend that users use ra_neon--the default for the 1.7.x series--when running svnrdump. To download the latest release of Subversion, please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release The SHA1 checksums are: eebeb77f1a8d352adcd8fe684b52e66be9fdcbce subversion-1.7.3.zip 624d4070361c0e8d7cf4f5c667629e72459b122d subversion-1.7.3.tar.bz2 0b97f7a3ebef31f3fc96f73eda2974eedee7aaf7 subversion-1.7.3.tar.gz PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.3.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.3.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.3.zip.asc 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 Paul T. Burba [1024D/53FCDC55] with fingerprint: E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55 Bert Huijben [1024D/9821F7B2] with fingerprint: 2017 F51A 2572 0E78 8827 5329 FCFD 6305 9821 F7B2 Hyrum K. Wright [1024D/4E24517C] with fingerprint: 3324 80DA 0F8C A37D AEE6 D084 0B03 AE6E 4E24 517C Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Stefan Sperling [1024D/F59D25F0] with fingerprint: B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0 Mark Phippard [1024D/035A96A9] with fingerprint: D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9 Release notes for the 1.7.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.7.html You can find the list of changes between 1.7.3 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.3/CHANGES Questions, comments, and bug reports to us...@subversion.apache.org. Thanks, - The Subversion Team
Moving our dist area to svnpubsub
Currently we publish releases by uploading them to a specified directory on scp://people.apache.org/. Infra would like to move from this model to a model where releases are stored in a Subversion repository[1]. I suggest that we join a few other PMC's who had already converted. The impact on us is that we'll be uploading releases by committing to [1]/subversion, rather than by scp'ing them. It will also shorten the wait period on mirroring new releases from 25 hours to 24 hours. Barring objections I'll follow up with infra in a few days to make this happen. Daniel [1] https://dist.apache.org/repos/dist/release/
Re: Moving our dist area to svnpubsub
On Mon, Feb 13, 2012 at 9:02 AM, Daniel Shahaf wrote: > Currently we publish releases by uploading them to a specified directory > on scp://people.apache.org/. > > Infra would like to move from this model to a model where releases are > stored in a Subversion repository[1]. > > I suggest that we join a few other PMC's who had already converted. The > impact on us is that we'll be uploading releases by committing to > [1]/subversion, rather than by scp'ing them. It will also shorten the > wait period on mirroring new releases from 25 hours to 24 hours. > > Barring objections I'll follow up with infra in a few days to make this > happen. That would be awesome. Despite my past obstinacy, I'm particularly attracted to the part where PMC members would be able to directly commit their signatures to the release area, where something (an svnpubsub instance?) then verifies the sigs. In addition to working with Infra, release.py would probably need to be updated. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
automatically verifying PGP sigs on dist.a.o Re: Moving our dist area to svnpubsub
[CC += infra] Hyrum K Wright wrote on Mon, Feb 13, 2012 at 09:08:26 -0600: > On Mon, Feb 13, 2012 at 9:02 AM, Daniel Shahaf > wrote: > > Currently we publish releases by uploading them to a specified directory > > on scp://people.apache.org/. > > > > Infra would like to move from this model to a model where releases are > > stored in a Subversion repository[1]. > > > > I suggest that we join a few other PMC's who had already converted. The > > impact on us is that we'll be uploading releases by committing to > > [1]/subversion, rather than by scp'ing them. It will also shorten the > > wait period on mirroring new releases from 25 hours to 24 hours. > > > > Barring objections I'll follow up with infra in a few days to make this > > happen. > > That would be awesome. Despite my past obstinacy, I'm particularly > attracted to the part where PMC members would be able to directly > commit their signatures to the release area, where something (an > svnpubsub instance?) then verifies the sigs. > +1. As to the implementation: we could run something off of svnpubsub to verify the signatures, but I wonder if it'd make more sense to do that ASF-wide in the pre-commit hook on dist.apache.org. Infra people --- thoughts? > In addition to working with Infra, release.py would probably need to be > updated. > > -Hyrum > > > -- > > uberSVN: Apache Subversion Made Easy > http://www.uberSVN.com/
Re: [RFC] Inheritable Properties
Thanks for your thoughts. One comment: Branko Čibej wrote on Sun, Feb 12, 2012 at 21:52:16 +0100: > The idea is that we'd always maintain the complete index, i.e., in order > to determine if path@15 exists, one only needs to search the index for > (path, rev <= 15, !deleted) -- which is trivial in a properly ordered > index. (Yes, this assumes that we record deletions in the index as well > as insertions.) > > All of this can be done with an append-only index representation. What > you can't do with append-only is represent forward history links, but -- > we're not representing them very well right now, are we. :) Within the append-only constraint one can implement forward links if one has, say, a separate file per revision. (So asking "where was foo@15 copied to" involves a linear scan of $REPOS/db/forward-links/15.) stsp and I even started on such a design on some branch somewhere --- but that branch has been abandoned as the motivation for it was rename tracking, which stsp figured he could solve better without the new FS feature.
Re: [RFC] Inheritable Properties
On 13.02.2012 17:09, Daniel Shahaf wrote: > Thanks for your thoughts. One comment: > > Branko Čibej wrote on Sun, Feb 12, 2012 at 21:52:16 +0100: >> The idea is that we'd always maintain the complete index, i.e., in order >> to determine if path@15 exists, one only needs to search the index for >> (path, rev <= 15, !deleted) -- which is trivial in a properly ordered >> index. (Yes, this assumes that we record deletions in the index as well >> as insertions.) >> >> All of this can be done with an append-only index representation. What >> you can't do with append-only is represent forward history links, but -- >> we're not representing them very well right now, are we. :) > Within the append-only constraint one can implement forward links if one > has, say, a separate file per revision. (So asking "where was foo@15 > copied to" involves a linear scan of $REPOS/db/forward-links/15.) > > stsp and I even started on such a design on some branch somewhere --- > but that branch has been abandoned as the motivation for it was rename > tracking, which stsp figured he could solve better without the new FS > feature. A separate file per revision has other problems, too. You'd quickly run out of inodes on ext-derived file systems, for example. -- Brane
Re: [RFC] Inheritable Properties
Branko Čibej wrote on Mon, Feb 13, 2012 at 17:52:01 +0100: > On 13.02.2012 17:09, Daniel Shahaf wrote: > > Thanks for your thoughts. One comment: > > > > Branko Čibej wrote on Sun, Feb 12, 2012 at 21:52:16 +0100: > >> The idea is that we'd always maintain the complete index, i.e., in order > >> to determine if path@15 exists, one only needs to search the index for > >> (path, rev <= 15, !deleted) -- which is trivial in a properly ordered > >> index. (Yes, this assumes that we record deletions in the index as well > >> as insertions.) > >> > >> All of this can be done with an append-only index representation. What > >> you can't do with append-only is represent forward history links, but -- > >> we're not representing them very well right now, are we. :) > > Within the append-only constraint one can implement forward links if one > > has, say, a separate file per revision. (So asking "where was foo@15 > > copied to" involves a linear scan of $REPOS/db/forward-links/15.) > > > > stsp and I even started on such a design on some branch somewhere --- > > but that branch has been abandoned as the motivation for it was rename > > tracking, which stsp figured he could solve better without the new FS > > feature. > > A separate file per revision has other problems, too. You'd quickly run > out of inodes on ext-derived file systems, for example. > Yeah, I was in theory mode in the previous mail. On the branch we didn't ignore those "implementation considerations" and went for 3 files per shard of 4k revisions. https://svn.apache.org/repos/asf/subversion/branches/fs-successor-ids/BRANCH-README > -- Brane
Re: [RFC] Make Python 2.5 minimum version for dev tools (including test suite)
On Thu, Feb 9, 2012 at 4:04 PM, Hyrum K Wright wrote: > I find myself wanting to use the 'with' statement in the test suite, > which was introduced in Python 2.5 Python 2.5 was released 5.5 years > ago, and while I'm sure somebody on some archaic platform somewhere > doesn't have it installed, I think we can reasonably assume that > Python 2.5 is generally available. For reference, we currently > require and SQLite that is only 2.5-years-old. > > (And for the historically minded among us, let's please don't repeat > the same bikeshed we had when we bumped to Python 2.4 3 years ago: > http://svn.haxx.se/dev/archive-2009-01/0266.shtml) > > I would like to recommend we bump our minimum required version for the > test suite and development tools to Python 2.5. The reaction here seems to be a muted "sounds good to me." I've updated the required files in r1243627. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: automatically verifying PGP sigs on dist.a.o Re: Moving our dist area to svnpubsub
2012/2/13 Daniel Shahaf : > [CC += infra] > > Hyrum K Wright wrote on Mon, Feb 13, 2012 at 09:08:26 -0600: >> On Mon, Feb 13, 2012 at 9:02 AM, Daniel Shahaf >> wrote: >> > Currently we publish releases by uploading them to a specified directory >> > on scp://people.apache.org/. >> > >> > Infra would like to move from this model to a model where releases are >> > stored in a Subversion repository[1]. >> > >> > I suggest that we join a few other PMC's who had already converted. The >> > impact on us is that we'll be uploading releases by committing to >> > [1]/subversion, rather than by scp'ing them. It will also shorten the >> > wait period on mirroring new releases from 25 hours to 24 hours. >> > >> > Barring objections I'll follow up with infra in a few days to make this >> > happen. >> >> That would be awesome. Despite my past obstinacy, I'm particularly >> attracted to the part where PMC members would be able to directly >> commit their signatures to the release area, where something (an >> svnpubsub instance?) then verifies the sigs. >> > > +1. > > As to the implementation: we could run something off of svnpubsub to > verify the signatures, but I wonder if it'd make more sense to do that > ASF-wide in the pre-commit hook on dist.apache.org. Infra people --- > thoughts? > Afaik there is already a cron job that does verification, http://people.apache.org/~henkp/ -> pgp checks -> sig/md5 checker documentation Do you think that the hook should verify that the key is "trusted" and reject the commit, or just nag? I, personally, would prefer nagging as there might be different issues, and PMC may need some time to resolve the issue. Best regards, Konstantin Kolinko
Re: [Issue 4087] bogus repos_id in wc.db for file externals
s...@tigris.org wrote on Mon, Feb 13, 2012 at 13:10:47 -0800: > http://subversion.tigris.org/issues/show_bug.cgi?id=4087 > > > > > > > --- Additional comments from s...@tigris.org Mon Feb 13 13:10:47 -0800 > 2012 --- > r1243694 attemps to work around the reported problem that prompted me to file > this issue. It ensures that all file externals use the same repository root > URL > as used by other files. I.e. whatever the svn:externals propery says, we'll > use > the URL to the repository that the working copy (or checkout) is using, > provided > the repository has the same UUID. How likely is this to break things? I know that UUID's are supposed to be unique. But in practice, if people _do_ have different repositories with the same UUID, this will break in odd ways. How likely is that if()'s condition to occur? > > -- > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=2922146 > > To unsubscribe from this discussion, e-mail: > [issues-unsubscr...@subversion.tigris.org].
Re: [Issue 4087] bogus repos_id in wc.db for file externals
On Tue, Feb 14, 2012 at 12:27:21AM +0200, Daniel Shahaf wrote: > s...@tigris.org wrote on Mon, Feb 13, 2012 at 13:10:47 -0800: > > http://subversion.tigris.org/issues/show_bug.cgi?id=4087 > > > > > > > > > > > > > > --- Additional comments from s...@tigris.org Mon Feb 13 13:10:47 -0800 > > 2012 --- > > r1243694 attemps to work around the reported problem that prompted me to > > file > > this issue. It ensures that all file externals use the same repository root > > URL > > as used by other files. I.e. whatever the svn:externals propery says, we'll > > use > > the URL to the repository that the working copy (or checkout) is using, > > provided > > the repository has the same UUID. > > How likely is this to break things? > > I know that UUID's are supposed to be unique. But in practice, if > people _do_ have different repositories with the same UUID, this will > break in odd ways. How likely is that if()'s condition to occur? We rely on UUIDs being unique in other cases, too, don't we? There is a real actual problem here where at least one user cannot check out old revisions with 1.7, which they can check out with 1.6. I would tend to give fixing this regression higher priority than people running into problems because they have set up their UUIDs the wrong way.
Re: [Issue 4087] bogus repos_id in wc.db for file externals
Stefan Sperling wrote on Mon, Feb 13, 2012 at 23:39:30 +0100: > On Tue, Feb 14, 2012 at 12:27:21AM +0200, Daniel Shahaf wrote: > > s...@tigris.org wrote on Mon, Feb 13, 2012 at 13:10:47 -0800: > > > http://subversion.tigris.org/issues/show_bug.cgi?id=4087 > > > > > > > > > > > > > > > > > > > > > --- Additional comments from s...@tigris.org Mon Feb 13 13:10:47 > > > -0800 2012 --- > > > r1243694 attemps to work around the reported problem that prompted me to > > > file > > > this issue. It ensures that all file externals use the same repository > > > root URL > > > as used by other files. I.e. whatever the svn:externals propery says, > > > we'll use > > > the URL to the repository that the working copy (or checkout) is using, > > > provided > > > the repository has the same UUID. > > > > How likely is this to break things? > > > > I know that UUID's are supposed to be unique. But in practice, if > > people _do_ have different repositories with the same UUID, this will > > break in odd ways. How likely is that if()'s condition to occur? > > We rely on UUIDs being unique in other cases, too, don't we? > Such as? The design of wc-ng assumes that, but I don't know offhand how much we actually _rely_ on that in today's wc.db-per-working-copy era. > There is a real actual problem here where at least one user cannot check > out old revisions with 1.7, which they can check out with 1.6. > I would tend to give fixing this regression higher priority than people > running into problems because they have set up their UUIDs the wrong way. Sure, people who misuuid just invite trouble. But I still wonder if this is the sort of change that merits a release notes entry.
Re: [Issue 4087] bogus repos_id in wc.db for file externals
On Tue, Feb 14, 2012 at 12:43:30AM +0200, Daniel Shahaf wrote: > Stefan Sperling wrote on Mon, Feb 13, 2012 at 23:39:30 +0100: > > We rely on UUIDs being unique in other cases, too, don't we? > > > > Such as? grep -r UUID shows "svn relocate" as one example. > The design of wc-ng assumes that, but I don't know offhand how much we > actually _rely_ on that in today's wc.db-per-working-copy era. > > > There is a real actual problem here where at least one user cannot check > > out old revisions with 1.7, which they can check out with 1.6. > > I would tend to give fixing this regression higher priority than people > > running into problems because they have set up their UUIDs the wrong way. > > Sure, people who misuuid just invite trouble. But I still wonder if > this is the sort of change that merits a release notes entry. Of course, there are valid reasons for repository UUIDs to match. E.g. when a write-through proxy setup is used. So this is a bit muddled and depends on what the UUID identifies -- a particular repository, or a repository with particular content. Essentially, the user decides which one of these possibilities applies. But if this change breaks anything because of UUID problems, it hits people who have a broken setup. After all, file externals must come from the "same" repository, and the UUID exists to tell whether any given URLs point to the "same" repository. I don't think we need to take special precautions at our end for this. I'd rather be concerned about other side effects in behaviour. This is about file externals, after all, so who knows what might break :) For this reason I've asked the original reporter to test the patch, too. Our regression tests are happy with this change, FWIW.
[RFC] Non-normalizing Unicode Composition Awareness (was: Let's discuss about unicode compositions for filenames!)
Title: Non-normalizing Unicode Composition Awareness Version: 0.1 (2012-02-14) Context === Within Unicode, some characters can in the unicode standard be represented in 2 different ways (composed/decomposed), while rendered equally on screen or in print. A unicode string (e.g. a file name) can be represented in 2 normalized forms (NFC/NFD) or mixed, i.e. multiple such characters where some are composed and others decomposed (rare). The majority of file systems (e.g. NTFS, Ext3) will accept a unicode filename in any form, store and give back in the form it was input. These file systems will typically even accept multiple files where the path looks identical on screen but the unicode string is different due to character composition. A minority of file systems (currently Mac OS X HFS+ only) will normalize the paths. In the case of HFS+, the path will be normalized into NFD and it will even be given back that way when listing the filesystem. Most significant differences from the majority of filesystems: - A file that is stored in NFC or mixed, will not be returned with an identical name. Generally considered a negative effect of the HFS+ unicode implementation. - Multiple files whose name is rendered equally cannot be stored in the same directory. Often considered an advantage. The topic has been described here: http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames - This RFC is not as complete in all areas, and depend on this note for additional context and issue description. - This RFC proposes a solution very similar to the note's solution 4, "Client and server-side path comparison routines". However, here it is proposed as a long term solution. - This RFC is essentially identical to what Erik H. proposes in this thread: http://svn.haxx.se/dev/archive-2010-09/0319.shtml Issue Description === - Subversion and most file systems currently allow creation of multiple paths, which in normalized form are identical. Hereafter referred to as "normalized-name collisions". This could cause significant upgrade issues for repositories containing such collisions, depending on which solution is implemented. See section "Legacy Data". - Users have difficulty understanding and managing "normalized-name collisions". It is difficult to know which file is which and one of the paths is typically not possible to type on a keyboard. - Mac OS X clients can not interoperate with non-OSX clients when paths contain composed characters (added by a non-OSX client). The working copies are broken directly after checkout/update on OSX. Tracked by: http://subversion.tigris.org/issues/show_bug.cgi?id=2464 Differences to case-sensitivity === - NFC/NFD look the same when rendered on screen. - Different case can be controlled with the keyboard, while unicode composition is more difficult. - Most modern case-insensitive file systems are case-preserving, i.e. they do not normalize to a preferred form and always return the same form that was stored. Normalizing file systems do not preserve the paths. Similarities to case-sensitivity === - If two Unicode strings differ only by letter case/composition, on some computer systems they refer to the same file, while on other systems they refer to different files. The same applies if two Unicode strings differ only by composition. The rules are set by each file system. - Subversion interoperates with different systems. When two file names that differ only by letter case are transferred from a case-sensitive system to a case-insensitive system, they will collide and Subversion should handle this in some friendly way. The same applies if two file names differ only by composition. To Normalize or Not to Normalize === Whether or not to normalize within a Subversion repository (server-side) has been debated. The note (unicode-composition-for-filenames) considers normalization to NFC to be the long term (2.x) solution. Referring to this feature as "repository normalization". There are implementation advantages with normalized paths which can simplify comparisons and storage. There are also reasons not to normalize: - A file system is generally expected to give back exactly what was stored, or refuse up-front. HFS+ has been criticized for not living up to this expectation, which is also the reason the Svn WC has issues on HFS+. Subversion can be considered a sort of file system, and could therefore be expected to live up to this expectation. - Compatibility is a high priority for Subversion. Introducing normalization/translation/etc is not unlikely to introduce compatibility issues, now or later. There is a principle that Subversion should not be a limiting factor or impose undue limitations on allowed characters, file names etc. - Introducing normalization tends to complicate the upgrade process, especially for repositories that contain "normalized-name collisions". This is
[l10n] Translation status report for trunk r1243778
Translation status report for trunk@r1243778 lang trans untrans fuzzy obs -- de2080 192 309 273 UUooo es2006 266 386 407 ++UUU~ fr2270 2 8 3 +~ it1861 411 563 228 +++U~~oo ja2000 272 448 653 ++UUU~ooo ko2143 129 173 73 ++U~~~ nb2059 213 327 381 +++UUU pl2085 187 286 158 UUo pt_BR1828 444 579 220 +++~~~oo sv1783 489 602 226 ++U~~~oo zh_CN2244 28 17 3 +~ zh_TW1764 508 630 286 ++U~~~oo
Re: Error While Checking out Git Repository
On Thu, Feb 9, 2012 at 6:53 PM, Greg Stein wrote: The S:txdelta element was not requested by the client, so it freaks > out when it sees the unknown element. > Makes sense, we just deployed an update that fixes that and a few other bits that turned up while testing with ra_serf. The chunked request encoding support has also been deployed, and I've been able to check out and manage repos from 1.7 clients using both ra_neon and ra_serf. Thanks for all the help, and feel free to follow up if something doesn't look right on our end. -- For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.
Re: Error While Checking out Git Repository
On Feb 14, 2012 12:01 AM, "Nick Hengeveld" wrote: > > On Thu, Feb 9, 2012 at 6:53 PM, Greg Stein wrote: > >> The S:txdelta element was not requested by the client, so it freaks >> out when it sees the unknown element. > > > Makes sense, we just deployed an update that fixes that and a few other bits that turned up while testing with ra_serf. > > The chunked request encoding support has also been deployed, and I've been able to check out and manage repos from 1.7 clients using both ra_neon and ra_serf. > > Thanks for all the help, and feel free to follow up if something doesn't look right on our end. Awesome, Nick! Thanks for the super timely response! I know that svn is a bit fringe for you, which makes it all the better :-) (now if only codeplex had anywhere near your kickass-ness...) Cheers, -g
