On Fri, Sep 12, 2014 at 04:21:09PM +0200, Michael Haggerty wrote:
> > But I still wonder how hard it would be to just remove lock_file structs
> > from the global list when they are committed or rolled back.
> [...]
>
> To make that change, we would have to remove entries from the list of
> lock_f
On 09/10/2014 10:13 AM, Jeff King wrote:
> [...]
> I did coincidentally have an interesting experience with our lockfile
> code earlier today, which I'd like to relate.
>
> I was running pack-refs on a repository with a very large number of
> loose refs (about 1.8 million). [...] Each call to lock
On 09/07/2014 04:21 PM, Torsten Bögershausen wrote:
>
> On 2014-09-06 09.50, Michael Haggerty wrote:
>> Sorry for the long delay since v3. This version mostly cleans up a
>> couple more places where the lockfile object was left in an
>> ill-defined state.
> No problem with the delay.
> The most i
On 09/10/2014 09:11 PM, Jeff King wrote:
> On Wed, Sep 10, 2014 at 09:51:03AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> Yes, we don't let normal fetchers see these repos. They're only for
>>> holding shared objects and the ref tips to keep them reachable.
>>
>> Are these individu
On 09/10/2014 06:51 PM, Junio C Hamano wrote:
> [...]
> I am wondering if it makes sense to maintain a single ref that
> reaches all the commits in this shared object store repository,
> instead of keeping these millions of refs. When you need to make
> more objects kept and reachable, create an o
On Wed, Sep 10, 2014 at 09:51:03AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes, we don't let normal fetchers see these repos. They're only for
> > holding shared objects and the ref tips to keep them reachable.
>
> Are these individual refs have relations to the real world after
Jeff King writes:
> Yes, we don't let normal fetchers see these repos. They're only for
> holding shared objects and the ref tips to keep them reachable.
Are these individual refs have relations to the real world after
they are created? To ask it another way, let's say that a branch in
a reposi
On Wed, Sep 10, 2014 at 05:25:36PM +0700, Duy Nguyen wrote:
> On Wed, Sep 10, 2014 at 3:13 PM, Jeff King wrote:
> > I was running pack-refs on a repository with a very large number of
> > loose refs (about 1.8 million). Needless to say, this ran very slowly
> > and thrashed the disk, as that's al
On Wed, Sep 10, 2014 at 3:13 PM, Jeff King wrote:
> I was running pack-refs on a repository with a very large number of
> loose refs (about 1.8 million). Needless to say, this ran very slowly
> and thrashed the disk, as that's almost 7G using 4K inodes. But it did
> eventually generate a packed-re
On Sat, Sep 06, 2014 at 09:50:14AM +0200, Michael Haggerty wrote:
> Sorry for the long delay since v3. This version mostly cleans up a
> couple more places where the lockfile object was left in an
> ill-defined state. Thanks to Johannes Sixt and Torsten Bögershausen
> for their review of v3.
>
>
Michael Haggerty writes:
> This series applies to the current "master". There is a trivial
> conflict between these changes and "next", and a few not-too-serious
> conflicts between these changes and Ronnie's reference-related series
> in "pu".
The conflicts weren't very pretty as rs/transaction
On 2014-09-06 09.50, Michael Haggerty wrote:
> Sorry for the long delay since v3. This version mostly cleans up a
> couple more places where the lockfile object was left in an
> ill-defined state.
No problem with the delay.
The most important question is if we do the lk->active handling right.
Se
Sorry for the long delay since v3. This version mostly cleans up a
couple more places where the lockfile object was left in an
ill-defined state. Thanks to Johannes Sixt and Torsten Bögershausen
for their review of v3.
I believe that this series addresses all of the comments from v1 [1],
v2 [2], a
13 matches
Mail list logo
