Branko Čibej writes:
> On 10.08.2012 01:15, Philip Martin wrote:
>> Philip Martin writes:
>>
>>> Yes, I think so. The process executes something like
>>>
>>>pragma locking_mode = exclusive;
>>>begin exclusive transaction;
>>>commit transaction;
>>>
>>> and then the lock persists unt
cmpil...@apache.org writes:
> Author: cmpilato
> Date: Thu Aug 9 16:16:07 2012
> New Revision: 1371282
>
> URL: http://svn.apache.org/viewvc?rev=1371282&view=rev
> Log:
> Fix a sandbox violation in prop_tests.py 35.
>
> * subversion/tests/cmdline/prop_tests.py
> (propget_redirection): Consult t
Philip Martin writes:
>>arglist = [svntest.main.svn_binary, 'propget', SVN_PROP_MERGEINFO, '-vR',
>> - wc_dir]
>> + '--config-dir', svntest.main.default_config_dir, wc_dir]
>
> The user should be able to avoid the FAIL by having the appropriate
> settings in their conf
On Fri, Aug 10, 2012 at 1:09 AM, Philip Martin
wrote:
> Ben Reser writes:
>
>> On Thu, Aug 9, 2012 at 12:51 PM, Johan Corveleyn wrote:
>>> What does a frozen repository actually look like for clients? I assume
>>> only write operations are affected. What happens to a commit or a
>>> propset or a
On 10.08.2012 10:10, Johan Corveleyn wrote:
> On Fri, Aug 10, 2012 at 1:09 AM, Philip Martin
> wrote:
>> Ben Reser writes:
>>
>>> On Thu, Aug 9, 2012 at 12:51 PM, Johan Corveleyn wrote:
What does a frozen repository actually look like for clients? I assume
only write operations are aff
Johan Corveleyn writes:
> So, say for a standard 1.8 FSFS repository, is there a timeout for
> commits? What's the timeout (is it configurable?)? How will the commit
> fail when it reaches the timeout?
I don't think there is a timeout for the main write-lock. There is a
10s timeout for the rep-
Branko Čibej writes:
> I suppose anything that can make changes to the repository -- commit and
> revprop change? -- should, if possible, detect the freeze and
> immediately return an appropriate error.
I don't see how that is possible: the freeze is just the write-lock.
The only difference betw
Philip Martin writes:
> This means that a big/long commit that has taken the
> rep-cache lock (sent the first text delta) will block the freeze until
> that commit completes/aborts.
For Apache the rep-cache lock is probably only held for the duration of
the HTTP request, not the whole commit. s
Branko Čibej writes:
> On 10.08.2012 01:15, Philip Martin wrote:
>> Philip Martin writes:
>>
>>> Yes, I think so. The process executes something like
>>>
>>>pragma locking_mode = exclusive;
>>>begin exclusive transaction;
>>>commit transaction;
>>>
>>> and then the lock persists unt
On Fri, Aug 10, 2012 at 2:20 AM, C. Michael Pilato wrote:
> Justin, you appear to have resurfaced (to a degree, at least). Did you ever
> complete this work?
No.
AFAICT, the rewrite of the XML parsing used in update.c and the Depth:
1 PROPFIND hasn't been completed either. I think it probably
On Thu, Aug 9, 2012 at 1:28 PM, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Thu, Aug 09, 2012 at 12:25:44 +0100:
>> Does this property hold for f6 / 1.8?
>
> It seems to me it would work via one of two methods,
>
> 1) rsync --delete the $rev.* files and then reconstruct the manifest on
> the tar
+1 to release. I committed my signature for the Windows zip
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Justin Erenkrantz writes:
> On Wed, Aug 8, 2012 at 1:40 PM, Philip Martin
> wrote:
>> Subversion 1.7.6 tarballs are now available for testing/signing by
>> committers. To obtain them please check out a working copy from
>> https://dist.apache.org/repos/dist/dev/subversion
>
> +1 for release.
>
>
Stefan Fuhrmann wrote on Fri, Aug 10, 2012 at 13:27:59 +0200:
> On Thu, Aug 9, 2012 at 1:28 PM, Daniel Shahaf wrote:
> > Daniel Shahaf wrote on Thu, Aug 09, 2012 at 12:25:44 +0100:
> >> Does this property hold for f6 / 1.8?
> >
> > It seems to me it would work via one of two methods,
> >
> > 1) rs
On Fri, Aug 10, 2012 at 9:06 AM, Philip Martin
wrote:
> Justin Erenkrantz writes:
>
>> On Wed, Aug 8, 2012 at 1:40 PM, Philip Martin
>> wrote:
>>> Subversion 1.7.6 tarballs are now available for testing/signing by
>>> committers. To obtain them please check out a working copy from
>>> https://di
[ forwarding to dev@ ]
Katherine Marsden wrote on Thu, Aug 09, 2012 at 11:36:58 -0700:
> Hello,
>
> Is there a way to add a comment to a subversion issue without
> agreeing to Colabnet terms? I would like to add the following
> question/comment to Issue 2725. Unfortunately, in my current
> posit
On Wed, Aug 8, 2012 at 7:40 PM, Philip Martin
wrote:
> Subversion 1.7.6 tarballs are now available for testing/signing by
> committers. To obtain them please check out a working copy from
> https://dist.apache.org/repos/dist/dev/subversion
>
> Please add your signatures to the .asc files there.
C
I (Julian Foad) wrote on 6 August 2012:
> OK, enabled in 1369896.
>
> --reintegrate forces a 1.7 reintegrate, unconditionally, at the moment; I
> haven't put a deprecation warning in there.
>
> Please let me know if anyone sees unexpected results from merge now.
>
> TODO:
>
> * Revise 'svn mer
On Fri, Aug 10, 2012 at 11:55 AM, wrote:
> Author: brane
> Date: Fri Aug 10 09:55:16 2012
> New Revision: 1371633
>
> URL: http://svn.apache.org/viewvc?rev=1371633&view=rev
> Log:
> On Windows, create the generated svn_private_config.h in the intermediate
> build directory so that different confi
I'm not aware of there being a way to avoid signing up to Tigris. I
suppose the nice thing to do would be to migrate our tracker to
Bloodhound, because that might be the only way to preserve issue
numbers. Of course, that'll have to wait for proper multi-prodct support
and a few other goodies in Bl
To be fair, Apache Bloodhound (incubating) is just one option. We
could preserve issue numbers with a migration to Bugzilla, Jira, or
Google Code. (not sure if other options have been raised as options,
in the past)
My leanings are towards Google Code's tracker, but I like the idea
that Apache Blo
21 matches
Mail list logo
