Noorul Islam K M wrote on Fri, Jul 08, 2011 at 10:08:55 +0530:
> Daniel Shahaf writes:
>
> > rhuij...@apache.org wrote on Thu, Jul 07, 2011 at 09:44:12 -:
> >
> >> Author: rhuijben
> >> Date: Thu Jul 7 09:44:12 2011
> >> New Revision: 1143731
> >>
> >> URL: http://svn.apache.org/viewvc?rev=
Hi Peter,
On Fri, Jul 8, 2011 at 10:41 AM, Peter Samuelson wrote:
> Historically the "uncompress / recompress / get original compressed
> file" process has been noticeably more reliable with bzip2 than gzip.
> Probably because there is only one canonical bzip2 implementation,
> whereas there are
[Senthil Kumaran S]
> In the above sha1sum of .bz2 file matches with whatever is published
> on the download link, but on the other hand, when I convert the bz2
> file to tar.gz, the sha1sum does not match the one provided in the
> download link for tar.gz, which was not the case in past.
Histori
Daniel Shahaf writes:
> rhuij...@apache.org wrote on Thu, Jul 07, 2011 at 09:44:12 -:
>
>> Author: rhuijben
>> Date: Thu Jul 7 09:44:12 2011
>> New Revision: 1143731
>>
>> URL: http://svn.apache.org/viewvc?rev=1143731&view=rev
>> Log:
>> Add testcase for issue #3787.
>>
>> * subversion/tes
On Wed, Jul 6, 2011 at 11:48 PM, Hyrum K Wright wrote:
> 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]. Yo
Hi Noorul,
On Mon, Jul 4, 2011 at 12:15 PM, Noorul Islam K M wrote:
> [[[
>
> * docs/community-guide/general.part.html
> Fix broken link to #partial-commit-access.
>
> Patch by: Noorul Islam K M
> ]]]
Thanks for the patch. Committed in r1144135.
--
Senthil Kumaran S
http://www.stylesen.org
On Thu, Jul 7, 2011 at 17:56, Stefan Sperling wrote:
> On Fri, Jul 08, 2011 at 12:49:37AM +0300, Daniel Shahaf wrote:
>> RFC:
>>
>> * Remove revprops.db code from trunk and 1.7
>> * Release 1.7 with FSFS f4
>> (this is the format that 1.6 used)
>> * Implement revprops packing in f6 and release t
On Thu, Jul 7, 2011 at 4:56 PM, Stefan Sperling wrote:
> On Fri, Jul 08, 2011 at 12:49:37AM +0300, Daniel Shahaf wrote:
>> RFC:
>>
>> * Remove revprops.db code from trunk and 1.7
>> * Release 1.7 with FSFS f4
>> (this is the format that 1.6 used)
>> * Implement revprops packing in f6 and release
On Fri, Jul 08, 2011 at 12:49:37AM +0300, Daniel Shahaf wrote:
> RFC:
>
> * Remove revprops.db code from trunk and 1.7
> * Release 1.7 with FSFS f4
> (this is the format that 1.6 used)
> * Implement revprops packing in f6 and release that in 1.8
+1
RFC:
* Remove revprops.db code from trunk and 1.7
* Release 1.7 with FSFS f4
(this is the format that 1.6 used)
* Implement revprops packing in f6 and release that in 1.8
This has seen some support on IRC, posting here for objections.
- Forwarded message from danie...@tigris.org -
>
C. Michael Pilato wrote on Thu, Jul 07, 2011 at 16:54:46 -0400:
> On 07/07/2011 04:50 PM, Daniel Shahaf wrote:
> > Hmm. For wc we have upgrade tests using tarred old working copies.
> > Perhaps we should do the same for svnadmin/fsfs?
> >
> > % grep upgrade svnadmin_tests.py | wc -l
> > 0
>
> We
On 07/07/2011 04:50 PM, Daniel Shahaf wrote:
> Hmm. For wc we have upgrade tests using tarred old working copies.
> Perhaps we should do the same for svnadmin/fsfs?
>
> % grep upgrade svnadmin_tests.py | wc -l
> 0
We haven't tested upgrades of filesystems in the past because we thus far
haven't
Hmm. For wc we have upgrade tests using tarred old working copies.
Perhaps we should do the same for svnadmin/fsfs?
% grep upgrade svnadmin_tests.py | wc -l
0
hwri...@apache.org wrote on Thu, Jul 07, 2011 at 20:47:01 -:
> Author: hwright
> Date: Thu Jul 7 20:47:01 2011
> New Revision: 114
On Thu, Jul 7, 2011 at 13:54, Peter Samuelson wrote:
>
> [Daniel Shahaf]
>> The only format 5 repositories we have right now 'in the wild' are
>> 1.7-dev code. revprops.db code was never included in a release.
>
> Well unless you count the alphas. But we _do_ warn people not to
> assume anything
Side comment: either of you should feel free to add these additions to
whatever is on the branch. I may have created it, but I don't
consider it anything close to private. Please feel free to hack away.
-Hyrum
On Thu, Jul 7, 2011 at 12:53 PM, Daniel Shahaf wrote:
> I'm indifferent as to alignm
I'm indifferent as to alignment, left alignment sounds fine as it's
easier for parsing and grepping.
Width: IMO 20, not 16, since offsets are 64-bit. (And there is no need
to be a power of 2, because (a) we use atomic move-into-place without
in-place edits, and (b) the sequence number is currentl
[Daniel Shahaf]
> The only format 5 repositories we have right now 'in the wild' are
> 1.7-dev code. revprops.db code was never included in a release.
Well unless you count the alphas. But we _do_ warn people not to
assume anything about them, right? Also, it's not like everyone who
downloaded
Greg Stein wrote on Thu, Jul 07, 2011 at 13:22:40 -0400:
> On Thu, Jul 7, 2011 at 10:21, wrote:
> >...
> > +++ subversion/branches/revprop-packing/subversion/libsvn_fs_fs/structure
> > Thu Jul 7 14:21:08 2011
> > @@ -40,7 +40,9 @@ repository) is:
> > revprops/ Subdirectory containin
On Thu, Jul 7, 2011 at 10:21, wrote:
>...
> +++ subversion/branches/revprop-packing/subversion/libsvn_fs_fs/structure Thu
> Jul 7 14:21:08 2011
> @@ -40,7 +40,9 @@ repository) is:
> revprops/ Subdirectory containing rev-props
> / Shard directory, if sharding is in use (
[Hyrum K Wright]
> I've created the revprop-packing branch to do the implementation. It
> currently has a skeleton BRANCH-README, which Daniel will be
> augmenting shortly.
This might open another small can o' worms, but "while we're already
bumping the format and rewriting the content...": each
[hwri...@apache.org]
> + /* Update the manifest. */
> + SVN_ERR(svn_stream_printf(manifest_stream, iterpool,
> +"%016" APR_OFF_T_FMT, next_offset));
> + next_offset += finfo.size;
Bikeshed time! I think space-padding (either %16 or %-16) would look
Pre pool cleanup is not in Apr 0.9.x if I remember correctly.
Bert Huijben (Cell phone) From: Daniel Shahaf
Sent: donderdag 7 juli 2011 18:59
To: dev@subversion.apache.org
Cc: comm...@subversion.apache.org; Alec Kloss
Subject: Re: svn commit: r1134032
- /subversion/trunk/subversion/svnserve/main.c
s...@apache.org wrote on Thu, Jun 09, 2011 at 18:39:44 -:
> Author: stsp
> Date: Thu Jun 9 18:39:43 2011
> New Revision: 1134032
>
> URL: http://svn.apache.org/viewvc?rev=1134032&view=rev
> Log:
> Fix issue #3664, "SASL support in inetd mode caused SIGSEGV during shutdown".
>
> Make sure svn
This was no heuristic. This was always guaranteed the right
information, because it was obtained from the wc just after obtaining
the write lock.
If this would be some heuristic ANY UPDATE would be some heuristic as
the update itself is driven based on the same information. (Except that
it is stor
On Thu, Jul 7, 2011 at 19:17, C. Michael Pilato wrote:
> On 07/07/2011 10:55 AM, i...@apache.org wrote:
>> Author: ivan
>> Date: Thu Jul 7 14:55:19 2011
>> New Revision: 1143860
>>
>> URL: http://svn.apache.org/viewvc?rev=1143860&view=rev
>> Log:
>> Fix calculation X-SVN-VR-Base request header in
rhuij...@apache.org wrote on Thu, Jul 07, 2011 at 09:44:12 -:
> Author: rhuijben
> Date: Thu Jul 7 09:44:12 2011
> New Revision: 1143731
>
> URL: http://svn.apache.org/viewvc?rev=1143731&view=rev
> Log:
> Add testcase for issue #3787.
>
> * subversion/tests/cmdline/info_tests.py
> (info_sh
[C. Michael Pilato]
> Boo! Layer knowledge violation. Ignoring, oh, the tiny percentage
> of Subversion code that does something special with r0 props, why
> would we special-case this?
It's special because we do ship svnsync officially. (:
It's special because r0 never has anything in it _exc
On 07/07/2011 10:55 AM, i...@apache.org wrote:
> Author: ivan
> Date: Thu Jul 7 14:55:19 2011
> New Revision: 1143860
>
> URL: http://svn.apache.org/viewvc?rev=1143860&view=rev
> Log:
> Fix calculation X-SVN-VR-Base request header in ra_serf.
>
> This commit reverts r1142065 and r1143089.
>
> *
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: donderdag 7 juli 2011 16:46
> To: Bert Huijben
> Cc: dev@subversion.apache.org; iss...@subversion.tigris.org
> Subject: Re: [Issue 3951] serf fail prop_tests.py 3 with 1.6 mod_dav_svn
>
> "Bert Huijben
> -Original Message-
> From: i...@apache.org [mailto:i...@apache.org]
> Sent: donderdag 7 juli 2011 16:55
> To: comm...@subversion.apache.org
> Subject: svn commit: r1143860 -
> /subversion/trunk/subversion/libsvn_ra_serf/update.c
>
> Author: ivan
> Date: Thu Jul 7 14:55:19 2011
> New Rev
On 07/07/2011 10:56 AM, Mark Phippard wrote:
> How about a new option?
>
> 4. Remove the f5 feature, release 1.7 without it and revisit when we
> can settle on a new design?
>
> IMO, it is too late to be considering a brand new design. If we are
> not comfortable with the current implementation
On Mon, Jul 4, 2011 at 18:49, Bert Huijben wrote:
>> -Original Message-
>> From: Hyrum K Wright [mailto:hy...@hyrumwright.org]
>> Sent: maandag 4 juli 2011 16:27
>> To: Subversion Development
>> Subject: Third (and probably last) alpha coming later this week
>>
>> Seeing Philip's commit of
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
"Bert Huijben" writes:
>> -Original Message-
>> From: phi...@tigris.org [mailto:phi...@tigris.org]
>> Sent: donderdag 7 juli 2011 12:56
>> To: iss...@subversion.tigris.org
>> Subject: [Issue 3951] serf fail prop_tests.py 3 with 1.6 mod_dav_svn
>>
>> http://subversion.tigris.org/issues/sh
On 07/07/2011 10:13 AM, Daniel Shahaf wrote:
> It means that all the '% ffd->max_files_per_dir' computations need to
> get an off-by-one iff they are for revprops. Special-casing r0 and the
> first shard's manifest seems to me, too, to be preferable.
Boo! Layer knowledge violation. Ignoring, oh
On Wed, Jul 6, 2011 at 12:35 PM, Stefan Sperling wrote:
> 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 infrastruct
Philip Martin wrote on Thu, Jul 07, 2011 at 14:54:10 +0100:
> Daniel Shahaf writes:
>
> > Hyrum K Wright wrote on Thu, Jul 07, 2011 at 08:29:31 -0500:
> >> On Thu, Jul 7, 2011 at 2:36 AM, Philip Martin
> >> wrote:
> >> >
> >> > r0 revprops are a concern, they can have different access patterns.
Daniel Shahaf writes:
> Hyrum K Wright wrote on Thu, Jul 07, 2011 at 08:29:31 -0500:
>> On Thu, Jul 7, 2011 at 2:36 AM, Philip Martin
>> wrote:
>> >
>> > r0 revprops are a concern, they can have different access patterns. For
>> > example a master/slave setup running svnsync once per revision (
Le 7 juillet 2011 09:38:08, Philip Martin a écrit :
> Stéphane Gaudreault writes:
> > Le 7 juillet 2011 08:43:06, Philip Martin a écrit :
> >> If you change the line in configure from
> >>
> >> SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `$PERL -MExtUtils::Embed -e
> >>
> >> ccopts`"
> >>
> >> to
On Wed, Jul 6, 2011 at 2:30 PM, 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 impleme
On Thu, Jul 7, 2011 at 8:39 AM, Daniel Shahaf wrote:
> Philip Martin wrote on Thu, Jul 07, 2011 at 08:36:06 +0100:
>> Daniel Shahaf writes:
>>
>> > The process to edit a revprop that had been packed would be:
>> >
>> > * grab write lock
>> > * prepare a new pack-file-with-inline-manifest
>> > * m
Philip Martin wrote on Thu, Jul 07, 2011 at 08:36:06 +0100:
> Daniel Shahaf writes:
>
> > The process to edit a revprop that had been packed would be:
> >
> > * grab write lock
> > * prepare a new pack-file-with-inline-manifest
> > * move-into-place, atomically replacing the previous pack file
>
Stéphane Gaudreault writes:
> Le 7 juillet 2011 08:43:06, Philip Martin a écrit :
>> If you change the line in configure from
>>
>> SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `$PERL -MExtUtils::Embed -e
>> ccopts`"
>>
>> to
>>
>> SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `unset CFLAGS; $PERL
>>
Philip Martin writes:
> Holding the write lock will block readers so for better concurrency we
> want to minimise the time that a write lock is held, or have more locks.
Daniel pointed out that readers don't block, they simply read the pack
file and get either the old or atomically replaced new
Hyrum K Wright wrote on Thu, Jul 07, 2011 at 08:29:31 -0500:
> On Thu, Jul 7, 2011 at 2:36 AM, Philip Martin
> wrote:
> >
> > r0 revprops are a concern, they can have different access patterns. For
> > example a master/slave setup running svnsync once per revision (a common
> > setup) will write
On Wed, Jul 6, 2011 at 2:18 PM, Hyrum K Wright wrote:
> 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
Le 7 juillet 2011 08:43:06, Philip Martin a écrit :
> Stéphane Gaudreault writes:
> > # perl -MExtUtils::Embed -e ccopts
> >
> > -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector
> > -I/usr/local/include -D_LARGEFILE_SOURCE -
> >
> > D_FILE_OFFSET_BITS=64 -I/usr/lib/perl
On Thu, Jul 7, 2011 at 2:36 AM, Philip Martin
wrote:
>
> r0 revprops are a concern, they can have different access patterns. For
> example a master/slave setup running svnsync once per revision (a common
> setup) will write the r0 pack file several times per revision. We don't
> want the pack fi
Stéphane Gaudreault writes:
> # perl -MExtUtils::Embed -e ccopts
> -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector
> -I/usr/local/include -D_LARGEFILE_SOURCE -
> D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/core_perl/CORE
>
> It seems that the new perl 5.14 ExtUtils::MakeMake
Le 7 juillet 2011 07:27:05, Philip Martin a écrit :
> Stéphane Gaudreault writes:
> >> What is the typdef line for apr_off_t in apr.h? It should be something
> >> that is 64bit irrespective of _FILE_OFFSET_BITS.
> >
> > typedef off64_t apr_off_t;
>
> So APR/Subversion are using 64-of
Stéphane Gaudreault writes:
>> What is the typdef line for apr_off_t in apr.h? It should be something
>> that is 64bit irrespective of _FILE_OFFSET_BITS.
>
> typedef off64_t apr_off_t;
So APR/Subversion are using 64-offsets irrespective of
_FILE_OFFSET_BITS.
>> Are there any occuren
> -Original Message-
> From: phi...@tigris.org [mailto:phi...@tigris.org]
> Sent: donderdag 7 juli 2011 12:56
> To: iss...@subversion.tigris.org
> Subject: [Issue 3951] serf fail prop_tests.py 3 with 1.6 mod_dav_svn
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3951
>
>
>
>
Le 6 juillet 2011 05:42:15, Philip Martin a écrit :
> 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 d
On Wed, Jul 06, 2011 at 01:18:35PM -0500, Hyrum K Wright wrote:
> 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
Daniel Shahaf writes:
> The process to edit a revprop that had been packed would be:
>
> * grab write lock
> * prepare a new pack-file-with-inline-manifest
> * move-into-place, atomically replacing the previous pack file
> * ungrab write lock
>
> That is what guarantees cp(1) consistency that Hyr
55 matches
Mail list logo
