On 08/22/2012 03:39 PM, Philip Martin wrote:
> I'm currently using BDB's svn_repos lock for the BDB freeze so that
> makes a BDB repository completely unreadable while frozen. No BDB
> commits can start while frozen. Starting a BDB freeze has to wait for
> in-progress commits to finish.
Strictly
On Thu, Aug 23, 2012 at 12:26 AM, Philip Martin
wrote:
> Johan Corveleyn writes:
>
>> Ok, let me try to decipher what that means for users.
>>
>> - New commit will block: does this mean that 'svn commit -mm somefile'
>> will simply hang (until the repository is unfrozen, or until the
>> client-si
Johan Corveleyn writes:
> Ok, let me try to decipher what that means for users.
>
> - New commit will block: does this mean that 'svn commit -mm somefile'
> will simply hang (until the repository is unfrozen, or until the
> client-side timeout is reached)? Can it be cancelled?
>
> - Commit in pro
On Wed, Aug 22, 2012 at 9:39 PM, Philip Martin
wrote:
> Johan Corveleyn writes:
>
>> On Fri, Aug 10, 2012 at 10:22 AM, Philip Martin
>> wrote:
>>> Johan Corveleyn writes:
>>>
So, say for a standard 1.8 FSFS repository, is there a timeout for
commits? What's the timeout (is it configur
Johan Corveleyn writes:
> On Fri, Aug 10, 2012 at 10:22 AM, Philip Martin
> wrote:
>> 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
On Fri, Aug 10, 2012 at 10:22 AM, Philip Martin
wrote:
> 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 time
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
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:
> 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
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-
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
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
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 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 until the database connection is clos
Mark Phippard writes:
> Does our write lock block svn lock/unlock as well as revprop edits?
Yes, for FSFS. I haven't investigated a BDB implementation of freeze.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
On Aug 9, 2012, at 7:15 PM, 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 until the database connectio
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 until the database connection is closed or
> the process exits.
I think it might also wo
Ben Reser writes:
> On Thu, Aug 9, 2012 at 12:51 PM, Johan Corveleyn wrote:
>> On Thu, Aug 9, 2012 at 10:06 AM, Philip Martin
>> wrote:
>>> The freeze-lock is similar to a write-lock: it exists for the duration
>>> of the process that creates it. For scripts my trial freeze-program has
>>> an
Stefan Fuhrmann writes:
> On Thu, Aug 9, 2012 at 10:06 AM, Philip Martin
> wrote:
>> The freeze-lock is similar to a write-lock: it exists for the duration
>> of the process that creates it.
>
> I see. Makes sense. Will it also work for the sqlite lock?
> (you mentioned that you would like to lo
On Thu, Aug 9, 2012 at 12:51 PM, Johan Corveleyn wrote:
> On Thu, Aug 9, 2012 at 10:06 AM, Philip Martin
> wrote:
>> The freeze-lock is similar to a write-lock: it exists for the duration
>> of the process that creates it. For scripts my trial freeze-program has
>> an interface like:
>>
>>fr
On Thu, Aug 9, 2012 at 10:06 AM, Philip Martin
wrote:
> Stefan Fuhrmann writes:
>
>> On Wed, Aug 8, 2012 at 4:57 PM, Mark Moe wrote:
>>> This would be useful for our us too. I would add "freeze" to the start and
>>> "unfreeze" to the end of the script we use to rsync a copy of our repo (and
>>>
On Thu, Aug 9, 2012 at 10:06 AM, Philip Martin
wrote:
> Stefan Fuhrmann writes:
>
>> On Wed, Aug 8, 2012 at 4:57 PM, Mark Moe wrote:
>>> This would be useful for our us too. I would add "freeze" to the start and
>>> "unfreeze" to the end of the script we use to rsync a copy of our repo (and
>>>
Stefan Fuhrmann writes:
> On Wed, Aug 8, 2012 at 4:57 PM, Mark Moe wrote:
>> This would be useful for our us too. I would add "freeze" to the start and
>> "unfreeze" to the end of the script we use to rsync a copy of our repo (and
>> associated files) to an off-site network share.
>
> If freeze
On Wed, Aug 8, 2012 at 4:57 PM, Mark Moe wrote:
> This would be useful for our us too. I would add "freeze" to the start and
> "unfreeze" to the end of the script we use to rsync a copy of our repo (and
> associated files) to an off-site network share.
If freeze and unfreeze can be used quasi-in
This would be useful for our us too. I would add "freeze" to the start and
"unfreeze" to the end of the script we use to rsync a copy of our repo (and
associated files) to an off-site network share.
Thanks,
- Mark
"C. Michael Pilato" writes:
> On 08/08/2012 07:38 AM, Philip Martin wrote:
>> I've been asked about using operating system snapshots to make backups
>> of live repositories. These could be filesytem snapshots like ZFS or
>> FreeBSD's UFS2, or block level snapshots like Linux's LVM, or maybe even
On 08/08/2012 07:38 AM, Philip Martin wrote:
> I've been asked about using operating system snapshots to make backups
> of live repositories. These could be filesytem snapshots like ZFS or
> FreeBSD's UFS2, or block level snapshots like Linux's LVM, or maybe even
> a Windows shadow copy. The reas
27 matches
Mail list logo
