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
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 reasons for using snapshots, rather than
"svnadmin hotcop
28 matches
Mail list logo
