Re: 1.7.0-alpha3 tarballs up for testing / signing

NOTE: The collect-sigs.py script is currently failing: [Errno 13] Permission denied: u'/home/hwright/dev/release/sigs/subversion-1.6.16.tar.bz2.asc' - Summary: +1 to release. Platform: Ubuntu 10.04 (lucid) Linux. Teste

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

Some discussion on IRC concerning editing manifest records in-place, rather than via move-into-place of a tempfile, boiled down to "manifest records should not cross OS page boundaries", and therefore "manifest record length (i.e., the number of bytes for one revision's manifest entry) should be a

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

> Peter Samuelson wrote on Wed, Jul 06, 2011 at 15:10:15 -0500: > > I still think it'd be possible, even practical, to create packfiles on > > the fly, instead of just explicitly via svnadmin pack. This requires [Daniel Shahaf] > What do you gain by that? The main thing you gain is a single cod

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

Peter Samuelson wrote on Wed, Jul 06, 2011 at 15:10:15 -0500: > > [Hyrum K Wright] > > Revprops wouldn't be packed until explicitly asked to do so by > > 'svnadmin pack' which means the frequent post-commit revprop editing > > wouldn't pose a performance problem. > > I still think it'd be possibl

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

[Hyrum K Wright] > Revprops wouldn't be packed until explicitly asked to do so by > 'svnadmin pack' which means the frequent post-commit revprop editing > wouldn't pose a performance problem. I still think it'd be possible, even practical, to create packfiles on the fly, instead of just explicitl

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

On Wed, Jul 6, 2011 at 2:55 PM, Ivan Zhakov wrote: > On Wed, Jul 6, 2011 at 23:30, Hyrum K Wright wrote: >> On Wed, Jul 6, 2011 at 11:47 AM, Daniel Shahaf wrote: >>> This thread is now the only non-FSFS release blocker (filed as #3944). >>> Last I checked there were at least three solutions sugg

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

On Wed, Jul 6, 2011 at 23:30, Hyrum K Wright wrote: > On Wed, Jul 6, 2011 at 11:47 AM, Daniel Shahaf wrote: >> This thread is now the only non-FSFS release blocker (filed as #3944). >> Last I checked there were at least three solutions suggested, but no >> consensus on which solution to implement

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

Hyrum K Wright wrote on Wed, Jul 06, 2011 at 14:30:15 -0500: > On Wed, Jul 6, 2011 at 11:47 AM, Daniel Shahaf wrote: > > This thread is now the only non-FSFS release blocker (filed as #3944). > > Last I checked there were at least three solutions suggested, but no > > consensus on which solution t

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

[Hyrum K Wright] > In addition, the revprop packfile manifest information won't be > cached, since the manifest may change. We don't anticipate this to > be a problem, since it only adds an extra seek() to the revprop > lookup process (rather than the open() + seek() in the rev packing > world).

Re: JavaHL Package structure

On Tue, Jul 5, 2011 at 5:00 PM, Hyrum K Wright wrote: > As you are a primary consumer of the JavaHL API, would you mind > looking it over so we can fix any remaining issues before the 1.7.x > branch?  I realize it's been stable for the past little while, but > some positive confirmation that thin

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

Stefan Sperling wrote on Wed, Jul 06, 2011 at 21:40:00 +0200: > On Wed, Jul 06, 2011 at 02:30:15PM -0500, Hyrum K Wright wrote: > > After a bit of thinking and discussion, Daniel and I have come up with > > what we think is an acceptable solution, and I'm posting it here for > > validation. (Danie

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

On Wed, Jul 06, 2011 at 02:30:15PM -0500, Hyrum K Wright wrote: > After a bit of thinking and discussion, Daniel and I have come up with > what we think is an acceptable solution, and I'm posting it here for > validation. (Daniel, please correct me if I've gotten something > wrong.) > > Revision

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

On Wed, Jul 6, 2011 at 11:47 AM, Daniel Shahaf wrote: > This thread is now the only non-FSFS release blocker (filed as #3944). > Last I checked there were at least three solutions suggested, but no > consensus on which solution to implement. > > Some suggestions were > > > 0. Leave things as they

1.7.0-alpha3 tarballs up for testing / signing

All, The next in our series of 1.7.0 prereleases is now posted for testing and signing: 1.7.0-alpha3. These are cut from trunk, and the magic rev is r1143483. The buildbots were green at that rev, and all tests pass for me locally[1]. You can find them here: http://people.apache.org/~hwright/sv

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

Daniel Shahaf wrote on Wed, Jul 06, 2011 at 19:47:23 +0300: > This thread is now the only non-FSFS release blocker (filed as #3944). s/non-FSFS/non-Serf/

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

Mark Phippard wrote on Wed, Jul 06, 2011 at 13:27:05 -0400: > On Wed, Jul 6, 2011 at 1:20 PM, Daniel Shahaf wrote: > > Mark Phippard wrote on Wed, Jul 06, 2011 at 13:01:58 -0400: > >> On Wed, Jul 6, 2011 at 12:47 PM, Daniel Shahaf wrote: > >> > This thread is now the only non-FSFS release blocker

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

On Wed, Jul 6, 2011 at 1:20 PM, Daniel Shahaf wrote: > Mark Phippard wrote on Wed, Jul 06, 2011 at 13:01:58 -0400: >> On Wed, Jul 6, 2011 at 12:47 PM, Daniel Shahaf wrote: >> > This thread is now the only non-FSFS release blocker (filed as #3944). >> > Last I checked there were at least three sol

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

Mark Phippard wrote on Wed, Jul 06, 2011 at 13:01:58 -0400: > On Wed, Jul 6, 2011 at 12:47 PM, Daniel Shahaf wrote: > > This thread is now the only non-FSFS release blocker (filed as #3944). > > Last I checked there were at least three solutions suggested, but no > > consensus on which solution to

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

On Wed, Jul 6, 2011 at 12:47 PM, Daniel Shahaf wrote: > This thread is now the only non-FSFS release blocker (filed as #3944). > Last I checked there were at least three solutions suggested, but no > consensus on which solution to implement. > > Some suggestions were > > > 0. Leave things as they

fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

This thread is now the only non-FSFS release blocker (filed as #3944). Last I checked there were at least three solutions suggested, but no consensus on which solution to implement. Some suggestions were 0. Leave things as they are 1. Allow packing revisions without packing revprops. (revpro

Re: RFC: Merge tracking, conflicts, and obstructions

On Wed, Jul 06, 2011 at 12:23:25PM -0400, Paul Burba wrote: > One alternative would be to stop nesting conflicts if merge tracking > is active and treat existing conflicts as obstructions. Using the > existing merge tracking infrastructure for marking skipped subtrees as > untouched by a merge, we

RFC: Merge tracking, conflicts, and obstructions

On IRC Bert has asked me on a couple occasions if merge tracking should treat exiting conflicts as obstructions. In 1.6 and currently in trunk, if an existing conflict is encountered during a merge we raise another conflict. For example: 1) We perform a merge that results in a conflict: 1.7.0

Re: Third (and probably last) alpha coming later this week

On Mon, Jul 4, 2011 at 9:26 AM, Hyrum K Wright wrote: > Seeing Philip's commit of the libtool fixes makes me want to roll > another alpha before we branch and start the RC train.  We American > revolutionaries are busy celebrating our independence today, so expect > tarballs Tuesday or Wednesday,

Re: Assert in svn-1.7-alpha2 svn_client_merge3

Can you reproduce this with a non-optimized build of Subversion? Many of the function arguments in the stack trace appear to be optimized out, making it less than useful. -Hyrum On Sat, Jul 2, 2011 at 11:13 AM, Barry Scott wrote: > I'm testing 1.7-alpha2 against pysvn using Fedora 15 and I'm se

RE: [PATCH] Issue 3947 - subversion fails with incorrect home directory/HOME variable

> -Original Message- > From: Noorul Islam K M [mailto:noo...@collab.net] > Sent: woensdag 6 juli 2011 12:39 > To: Subversion > Subject: [PATCH] Issue 3947 - subversion fails with incorrect home > directory/HOME variable > [[[ > > * subversion/svn/main.c > (main): Fallback to default c

Issue #1532 - Switch a file to a dir: can't switch it back to the file

svn switch ^/dir_url file_path # This worked, but then ... svn switch ^/file_url file_path # this errored out. I filed this issue back in 2003 and it was unfixable then, but with WC-NG it should be relatively easy, so I'm trying.

Error during scn cleanup: svn: E720003: Can't open ...\.svn\tmp\....

Hi! Running svn command line client build from r1142137 (provided by TortoiseSVN 1.6.99.21659) OS: Windows XP SP3 32-bit I had to roll the system back to a restore point created several days ago. It broke one of my working copies, so that a lot of files in it have disappeared. The problem is t

[PATCH] Issue 3947 - subversion fails with incorrect home directory/HOME variable

In the issue tracker, Sam said: === issuing svn --version fails if running under user with non-directory as home directory. The same applies for incorrectly set $HOME variable. There is imho also no reason to create $HOME/.subvers

Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine

Stéphane Gaudreault writes: > # apr-1-config --cflags > -pthread > > # apr-1-config --cppflags > -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE So that is the standard APR with large-file support. APR doesn't use -D_FILE_OFFSET_BITS=64 because it defines its own 64bit apr_off_t a