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_file
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
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 p...@peff.net 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
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 important
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
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.
I
On Wed, Sep 10, 2014 at 3:13 PM, Jeff King p...@peff.net 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
On Wed, Sep 10, 2014 at 05:25:36PM +0700, Duy Nguyen wrote:
On Wed, Sep 10, 2014 at 3:13 PM, Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
On Wed, Sep 10, 2014 at 09:51:03AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Michael Haggerty mhag...@alum.mit.edu 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
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.
Set
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],
13 matches
Mail list logo
