Re: 1.6.12 tarballs up for signing / testing
On 6/20/2010 7:43 PM, Paul Querna wrote: > On Thu, Jun 17, 2010 at 5:37 PM, Hyrum K. Wright > wrote: >> 1.6.12 tarballs are up for testing and signing. The magic revision is >> r955767: >> http://people.apache.org/~hwright/svn/1.6.12/ >> >> As usual, signatures from full committers please send back to me. >> Testing by enthusiastic users is also welcomed (but remember that this >> is not yet a blessed release, with all that that implies). If you are >> a package maintainer, please do not included this release in your >> distribution until after it has been formally released. >> >> I'd like to collect all the signatures in time to do a release by June 21. > > 1.6.12 is now running on the ASF Subversion servers, both the master and > slave: > http://svn.us.apache.org/server-status > http://svn.eu.apache.org/server-status > > No new issues[1], but be sure to let us know if you see anything odd :) > > [1] - only 'painful' issue is the serf build and linking integration > on freebsd is prone... not working, but this has been the case ever > since serf support was added. Yes, I am a serf committer. I disagree. I've used serf at $work from ports since inception or at least 3 years ago. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: Subversion 1.6.12 Released
Hi, sorry...ignore the last patch i sent there was a wrong release date for 1.6.12 ...;-( Attached a new one.. Sorry.. Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de Index: publish/docs/release-notes/release-history.html === --- publish/docs/release-notes/release-history.html (revision 956647) +++ publish/docs/release-notes/release-history.html (working copy) @@ -31,6 +31,12 @@ +Subversion 1.6.12 (Monday, 21 June 2010): Bugfix release. + + +Subversion 1.6.11 (Friday, 16 April 2010): Bugfix release. + + Subversion 1.6.9 (Monday, 25 January 2010): Bugfix release. Index: publish/docs/release-notes/1.2.html === --- publish/docs/release-notes/1.2.html (revision 956647) +++ publish/docs/release-notes/1.2.html (working copy) @@ -60,7 +60,7 @@ For binary packages, please see the binary package +href="/packages.html">the binary package list. Note that binary packages usually come out about a week after the corresponding source release. The package maintainers are volunteers, so please don't harass them — they know Index: publish/docs/release-notes/1.3.html === --- publish/docs/release-notes/1.3.html (revision 956647) +++ publish/docs/release-notes/1.3.html (working copy) @@ -60,7 +60,7 @@ For binary packages, please see the binary package +href="/packages.html">the binary package list. Note that binary packages usually come out about a week after the corresponding source release. The package maintainers are volunteers, so please don't harass them — they know @@ -147,7 +147,7 @@ part of some other change pulled down via an OS package delivery mechanism — for example, upgrading one's Subversion package. If this happens to you, you will need -to upgrade existing BerkeleyDB-based +to upgrade existing BerkeleyDB-based repositories to 4.3. Since Subversion 1.2, the
Re: Subversion 1.6.12 Released
Hi there, just recognized some little things on the web site... The old release notes has some problems with two links in 1.2 and 1.3 and the release history is currently not complete (1.6.11 and 1.6.12 missing). On the other hand the CHANGES file for the 1.6.11 release is given the 19. of April as the release date where as the developers list is giving the 16. of April... Just attached a small patch to fix the things in the web site... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de Index: publish/docs/release-notes/release-history.html === --- publish/docs/release-notes/release-history.html (revision 956644) +++ publish/docs/release-notes/release-history.html (working copy) @@ -31,6 +31,12 @@ +Subversion 1.6.12 (Monday, 19 June 2010): Bugfix release. + + +Subversion 1.6.11 (Friday, 16 April 2010): Bugfix release. + + Subversion 1.6.9 (Monday, 25 January 2010): Bugfix release. Index: publish/docs/release-notes/1.2.html === --- publish/docs/release-notes/1.2.html (revision 956644) +++ publish/docs/release-notes/1.2.html (working copy) @@ -60,7 +60,7 @@ For binary packages, please see the binary package +href="/packages.html">the binary package list. Note that binary packages usually come out about a week after the corresponding source release. The package maintainers are volunteers, so please don't harass them — they know Index: publish/docs/release-notes/1.3.html === --- publish/docs/release-notes/1.3.html (revision 956644) +++ publish/docs/release-notes/1.3.html (working copy) @@ -60,7 +60,7 @@ For binary packages, please see the binary package +href="/packages.html">the binary package list. Note that binary packages usually come out about a week after the corresponding source release. The package maintainers are volunteers, so please don't harass them — they know @@ -147,7 +147,7 @@ part of some other change pulled down via an OS package delivery mechanism — for example, upgrading one's Subversion package. If this happens to you, you will need -to upgrade existing BerkeleyDB-based +to upgrade existing BerkeleyDB-based repositories to 4.3. Since Subversion 1.2, the
Re: svn commit: r956593 - /subversion/trunk/subversion/libsvn_delta/text_delta.c
On Jun 21, 2010, at 9:56 AM, julianf...@apache.org wrote: Author: julianfoad Date: Mon Jun 21 13:56:30 2010 New Revision: 956593 URL: http://svn.apache.org/viewvc?rev=956593&view=rev Log: Optimize the copies performed by svn_txdelta_apply_instructions(). svn_txdelta_apply_instructions() is relatively slow for long instruction sequences copying small pieces of data. This is particularly visible in "format 2" FSFS repositories. Two kinds of copy are involved. For simple copies, the system's memcpy() is used, which is fast for long lengths; this patch bypasses it for very short lengths. For intentionally overlapping copies, a custom loop is used, which was already fast for very short lengths; this patch adds a code path that is fast for longer lengths. Hi Julian, Does this turn out to have a measurable performance improvement? I would guess svn is limited by IO speeds with fsync(), not memory copies. Not that I don't appreciate performance improvements, running a backend that gets over 2 commits per second :), I'm just curious. Regards, Blair
[PATCH] Re: svnserve via xinetd segfaults
On 2010-04-18 14:42, Aaron Turner wrote: > On Sun, Apr 18, 2010 at 11:58 AM, Kevin Grover wrote: > > On Sat, Apr 17, 2010 at 10:12 PM, Aaron Turner wrote: > >> Not sure why, but sometimes svnserve segfaults when it runs via > >> xinetd. It turns out to be highly repeatable for specific svn > >> transactions/commands. Ie: > >> > >> svn merge -c 2454 . ../../branches/3.4/src > >> > >> causes the segfault, but another svn command works fine (I had just > >> done a number of commits). I've seen it happen with svn update as > >> well, so it doesn't seem specific to merge. This is a 100% reproducable event for me when running svnserve in inetd mode (started from daemontools' tcpserver). The issue is the SASL cleanup functions are called out of order, with sasl_done() being called before server_dispose(). I believe this happens because APR calls pool cleanup functions in the same order that they were registered in, and the global cleanup registration for sasl_done() is called prior to the cleanup registration for the server (which makes sense). The easiest way I found to resolve this is to create a connection pool even in the inetd case (which is how the other server cases work in svnserve). For Subversion 1.6.9: app1 subversion-1.6.9 # diff -u main.c.orig subversion/svnserve/main.c --- main.c.orig 2010-06-21 09:33:20.784733858 -0500 +++ subversion/svnserve/main.c 2010-06-21 09:33:31.154731019 -0500 @@ -599,8 +599,9 @@ return svn_cmdline_handle_exit_error(err, pool, "svnserve: "); } - conn = svn_ra_svn_create_conn(NULL, in_file, out_file, pool); - svn_error_clear(serve(conn, ¶ms, pool)); + connection_pool = svn_pool_create(pool); + conn = svn_ra_svn_create_conn(NULL, in_file, out_file, connection_pool); + svn_error_clear(serve(conn, ¶ms, connection_pool)); exit(0); } app1 subversion-1.6.9 # Should I create an official bug in Subversion's bug tracker? -- alec.kl...@oracle.com Oracle Middleware PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEBD1FF14 pgpXbF1bW1cdH.pgp Description: PGP signature
Subversion 1.6.12 Released
I'm happy to announce Subversion 1.6.12, available from: http://subversion.tigris.org/downloads/subversion-1.6.12.tar.bz2 http://subversion.tigris.org/downloads/subversion-1.6.12.tar.gz http://subversion.tigris.org/downloads/subversion-1.6.12.zip http://subversion.tigris.org/downloads/subversion-deps-1.6.12.tar.bz2 http://subversion.tigris.org/downloads/subversion-deps-1.6.12.tar.gz http://subversion.tigris.org/downloads/subversion-deps-1.6.12.zip The MD5 checksums are: a4b1d0d7f3a4587c59da9c1acf9dedd0 subversion-1.6.12.tar.bz2 ae008ac355581c90494fba86cbfc3413 subversion-1.6.12.tar.gz bca3aeec62d8f1185ec5d4dd24c00675 subversion-1.6.12.zip 41a91aa26980236958ec508807003203 subversion-deps-1.6.12.tar.bz2 90f3422dffa659c3d2711fb9354f6cb6 subversion-deps-1.6.12.tar.gz e3474f3ba6b0868d2847595fbf472e42 subversion-deps-1.6.12.zip The SHA1 checksums are: b4ae7c75abbbdade8b2c9122ca7e2e26c6468a82 subversion-1.6.12.tar.bz2 540ceebdc46721032f772bd713acc28496ec4ab8 subversion-1.6.12.tar.gz 35a6c5f9b24ccb61aad67d3c179270c706354971 subversion-1.6.12.zip b34772925366a82851752322e005a24a9e96ad0c subversion-deps-1.6.12.tar.bz2 9259af728425808cbf84a286555fc2d30a843eeb subversion-deps-1.6.12.tar.gz 60f6c5b623e226b2be0d15c0189700d62a7b8918 subversion-deps-1.6.12.zip PGP Signatures are available at: http://subversion.tigris.org/downloads/subversion-1.6.12.tar.bz2.asc http://subversion.tigris.org/downloads/subversion-1.6.12.tar.gz.asc http://subversion.tigris.org/downloads/subversion-1.6.12.zip.asc http://subversion.tigris.org/downloads/subversion-deps-1.6.12.tar.bz2.asc http://subversion.tigris.org/downloads/subversion-deps-1.6.12.tar.gz.asc http://subversion.tigris.org/downloads/subversion-deps-1.6.12.zip.asc For this release, the following people have provided PGP signatures: Senthil Kumaran S [1024D/6CCD4038] with fingerprint: 8035 16A5 1D6E 50E2 1ECD DE56 F68D 46FB 6CCD 4038 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 Arfrever Frehtes Taifersar Arahesis [4096R/7394B7E0] with fingerprint: 58BA 3F93 2C86 9DC4 AFF2 D33C 5537 FF0D 7394 B7E0 Julian Foad [1024D/353E25BC] with fingerprint: 6604 5A4B 43BC F994 5728 351F 33E4 353E 25BC 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 Mark Phippard [1024D/035A96A9] with fingerprint: D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9 Release notes for the 1.6.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.6.html You can find the list of changes between 1.6.12 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.6.12/CHANGES Questions, comments, and bug reports to us...@subversion.apache.org. Thanks, - The Subversion Team
Re: How use patch_target_t for both files and (possibly multiple) properties
On Mon, Jun 21, 2010 at 11:12:43AM +0200, Stefan Sperling wrote:
> On Sun, Jun 20, 2010 at 09:53:29PM +0200, Daniel Näslund wrote:
> > Hi stsp!
> >
> > Attaching a patch showing a suggestion on how to split up
> > patch_target_t. Maybe you have some insights on this, before I rush out
> > and start grooking around and making changes to your design.
> >
> > What 'svn patch' does
> > --
> > 1) Match hunks
> > 2) Apply hunks to a stream backed up by a tmp file
> > 3) Install. copy the tmp file to the target location
> > 4) Notify the user on what has happened, e.g. fuzz, offset and rejects
> >
> > The problem
> > -
> > Each property is essentially like it's own text file. 'svn patch' must
> > be generic enough to be able to perform the above actions on both
> > properties and texts.
> >
> > Alternatives
> > --
> > * Simplify. Don't use the unidiff format but just copy the content
> > straight off and apply it.
>
> I don't think I understand the above. What do you mean?
I was just thinking: We usually have properties that are limited in
size. We could just put the whole contents of the property after a header
in the diff file, e.g. not use the unidiff format. Then we could ignore
step 1) and 2) and just install the property and do the notification
according to what the diff header said, e.g added, deleted or modified.
I'm not proposing that we do it like that, but it's just that using
diffs for something that is typically one line or one word is a lot of
overhead. *But*, the properties can be longer; Tortoisesvn has a
tsvn:logtemplate property for instance.
> > * Duplicate. Create special code for handling props, e.g. have both
> > match_hunk() and match_property_hunk() and so on.
What you're proposing below is to duplicate the matching and applying of
properties. My thought was that we've put in a lot of thoughts to the
matching and applying and have encountered quite a few edge cases
involving newlines, fuzz and offsets. I was just hoping that we could
reuse our existing code.
> > Proposed solution
> > ---
> > Use patch_target_t as a container for sub-patch_targets that can be either
> > file-text or a property. Store tree change info needed for step 3)
> > installing and step 4) notifying.
>
> Your description is quite low-level (detailing new fields in existing
> structs etc.) which makes it a bit hard to follow.
I agree on that when rereading my mail, what did I really mean? :)
> Let's take a step back. What is the general idea of your approach?
To be able to use properties and text diffs in the same way when
matching and applying hunks.
> I'll try making some high-levelI suggestions about how to approach the
> problem. Please comment on them (I am most likely not seeing the whole
> picture) and we'll work something out.
>
> parse_next_hunk() currently puts both normal and property hunks
> in the same list (patch->hunks). Have you considered splitting this into
> two separate lists, e.g. patch->hunks and patch->property_hunks?
Since r955844, we put property hunks in patch->property_hunks and text
hunks in patch->hunks. :)
> property_hunks can be a hashtable with prop_name as keys and
> arrays of hunk_t as value: {prop_name, [hunk1, hunk2, hunk3, ...]}.
Since r955844, that is the approach.
> Or it can be a list of structs like { prop_name; array of hunks; }
> if that is easier to work with in the caller.
>
> This should provide much cleaner separation, because now you can
> leave the original hunk handling code alone, and add extra steps
> that handle the property cases.
>
> Regarding parse_next_hunk(), consider splitting this up into two
> functions: parse_hunk() and parse_property_hunk().
> The first one attempts to find a normal "@@" hunk at the current file
> offset, and returns a NULL *hunk on parsing failure. If it fails
> (the hunk returned is NULL), rewind the file to the seek position
> where parsing a normal hunk failed, and parse_property_hunk() to
> attempt parsing a "##" property hunk.
> These functions could probably share some code, but you should keep
> them independent for now so we can see how much they really differ.
I considered using that approach but thought that seeking around would
be messy. I didn't have to add too many if statements [1]. I reused the
parse code by allowing atat to be either '@@' or '##'. Maybe I was a bit
too enthusiastic and committed my changes too quickly. I'm able to use
parse_next_hunk() for both properties and hunks but maybe it just
obfuscates the code.
> In the patch code, you can then add property patching as a separate step.
> Currently, we do something like the following in apply_one_patch():
>
> for hunk in hunks:
> match(hunk)
> # gather some additional meta data on hunk such as actual line
> # offset we'll be using
> hunk_info = get_info(hunk)
> target.hunks.append(hunk_info)
>
> for hunk_info in target.hunks:
> if hunk.rejected:
> reject(hunk)
RE: 1.6.12 tarballs up for signing / testing
> -Original Message- > From: hy...@hyrumwright.org [mailto:hy...@hyrumwright.org] On Behalf > Of Hyrum K. Wright > Sent: vrijdag 18 juni 2010 2:37 > To: Subversion Development > Subject: 1.6.12 tarballs up for signing / testing > > 1.6.12 tarballs are up for testing and signing. The magic revision is r955767: > http://people.apache.org/~hwright/svn/1.6.12/ > > As usual, signatures from full committers please send back to me. > Testing by enthusiastic users is also welcomed (but remember that this > is not yet a blessed release, with all that that implies). If you are > a package maintainer, please do not included this release in your > distribution until after it has been formally released. > > I'd like to collect all the signatures in time to do a release by June 21. > > -Hyrum +1 for release Windows 7 x64 Visual Studio 2008 SP1 (32 bit) [bdb | fsfs] x [local | svn | serf | neon] APR 1.3.12 APR-Util 1.3.9 BDB 4.4.20 ZLib 1.2.5 Cyrus Sasl 2.1.23 Neon 0.29.3 OpenSSL 1.0.0 Serf 0.3.1 SqLite 3.6.23.1 Swig 1.3.38 Apache httpd 2.2.15 (With IPv6 enabled in APR and Neon) No test failures. == subversion-1.6.12.tar.bz2.asc == -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAkwfPacACgkQ/P1jBZgh97Ih+gCfcUPk6sG/RnQDuw8ynjcrs3nL RiUAoMwxqZMnj1cYxf2HWPjVcT3Kd38L =G4JG -END PGP SIGNATURE- == subversion-1.6.12.tar.gz.asc == -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAkwfPasACgkQ/P1jBZgh97KU2ACgwUONtPk9QZgwBkigfH1EkYKL UlcAn1HTOqHikheZw6Gd8NMru+lyIKQr =LVGZ -END PGP SIGNATURE- == subversion-1.6.12.zip.asc == -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAkwfPa8ACgkQ/P1jBZgh97I/igCcCCZs+gYEP/WggwH5JWjFh7K+ FnkAn1qP5WAP8UVkSdRrZRIazPbWS670 =+GEG -END PGP SIGNATURE- == svn_version.h.dist.asc == -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAkwfPbMACgkQ/P1jBZgh97IbNACeM5kVN+AivpDI+qYTNAgnAkzy o+gAnj+Wtok6vPMOk3KUclK2iVaXoyaU =BB9V -END PGP SIGNATURE-
Re: How use patch_target_t for both files and (possibly multiple) properties
On Sun, Jun 20, 2010 at 09:53:29PM +0200, Daniel Näslund wrote:
> Hi stsp!
>
> Attaching a patch showing a suggestion on how to split up
> patch_target_t. Maybe you have some insights on this, before I rush out
> and start grooking around and making changes to your design.
>
> What 'svn patch' does
> --
> 1) Match hunks
> 2) Apply hunks to a stream backed up by a tmp file
> 3) Install. copy the tmp file to the target location
> 4) Notify the user on what has happened, e.g. fuzz, offset and rejects
>
> The problem
> -
> Each property is essentially like it's own text file. 'svn patch' must
> be generic enough to be able to perform the above actions on both
> properties and texts.
>
> Alternatives
> --
> * Simplify. Don't use the unidiff format but just copy the content
> straight off and apply it.
I don't think I understand the above. What do you mean?
> * Duplicate. Create special code for handling props, e.g. have both
> match_hunk() and match_property_hunk() and so on.
>
> Proposed solution
> ---
> Use patch_target_t as a container for sub-patch_targets that can be either
> file-text or a property. Store tree change info needed for step 3)
> installing and step 4) notifying.
Your description is quite low-level (detailing new fields in existing
structs etc.) which makes it a bit hard to follow. Let's take a step back.
What is the general idea of your approach?
I'll try making some high-levelI suggestions about how to approach the
problem. Please comment on them (I am most likely not seeing the whole
picture) and we'll work something out.
parse_next_hunk() currently puts both normal and property hunks
in the same list (patch->hunks). Have you considered splitting this into
two separate lists, e.g. patch->hunks and patch->property_hunks?
property_hunks can be a hashtable with prop_name as keys and
arrays of hunk_t as value: {prop_name, [hunk1, hunk2, hunk3, ...]}.
Or it can be a list of structs like { prop_name; array of hunks; }
if that is easier to work with in the caller.
This should provide much cleaner separation, because now you can
leave the original hunk handling code alone, and add extra steps
that handle the property cases.
Regarding parse_next_hunk(), consider splitting this up into two
functions: parse_hunk() and parse_property_hunk().
The first one attempts to find a normal "@@" hunk at the current file
offset, and returns a NULL *hunk on parsing failure. If it fails
(the hunk returned is NULL), rewind the file to the seek position
where parsing a normal hunk failed, and parse_property_hunk() to
attempt parsing a "##" property hunk.
These functions could probably share some code, but you should keep
them independent for now so we can see how much they really differ.
In the patch code, you can then add property patching as a separate step.
Currently, we do something like the following in apply_one_patch():
for hunk in hunks:
match(hunk)
# gather some additional meta data on hunk such as actual line
# offset we'll be using
hunk_info = get_info(hunk)
target.hunks.append(hunk_info)
for hunk_info in target.hunks:
if hunk.rejected:
reject(hunk)
else
apply(hunk)
Rejection and application happens on temporary files, we haven't
modified the working copy yet.
It's clear that you'll need similar steps for properties. Something like:
for (prop, hunks) in property_hunks:
target.properties.append(prop)
for hunk in hunks:
match(hunk)
# gather some additional meta data on hunk such as actual line
# offset we'll be using
hunk_info = get_info(hunk)
target.properties.prop.hunks.append(hunk_info)
for prop in target.properties:
for hunk in prop.hunks:
if hunk.rejected:
reject(hunk)
else
apply(hunk)
This would also operate entirely on temporary files.
Once we're here, we can worry about applying the changes to the WC.
Again, I think it would help if you kept all property steps separate
from the existing code in the beginning. Just add new steps to
apply_one_patch() as needed, but don't modify existing code.
We can worry about optimizing the integration of the new code with the
existing code later. It's more important to focus on the problem itself
rather than worrying how to best integrate it with the existing code.
Just keep in mind to release all resources allocated for a target
before processing the next target. This is really important because
otherwise we use too much memory and/or file descriptors with large
patches.
Stefan
Re: Why am I getting a bad merge?
On Sat, 2010-06-19, Steven Boswell II wrote: > (I asked this question almost a month ago on the users list, but got > no response, so now I'm trying the developers list.) Hi Steven. I'm sorry to hear you're having difficulty using Subversion. Please re-post your question to the users list and I very much hope someone can help you solve it. (The "dev" list is for discussing the development of Subversion.) A small suggestion: sometimes readers are more likely to respond if they can see a list of the precise commands you ran, followed by the actual result and the expected result. Regards, - Julian
