Re: [jgit-dev] Problems with bitmaps and cloning and DFS back end

[Alex Blewitt <alex.blewitt@xxxxxxxxx>]

On 19 Jun 2013, at 17:03, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:

> On Wed, Jun 19, 2013 at 7:40 AM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
>> On 18 Jun 2013, at 20:13, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
>> 
>>> I've been having some problems with the new bitmap support in conjunction with a DFS back end.
>> 
>> So I think I've traced it down to a potential lack of saved info in my pack description.
>> 
>> There is a method "getObjectCount" which is currently returning zero. It looks like the pack needs that data when going down the "reuse cached packs" path. Until now this information hasn't needed to be passed/stored.
>> 
>> Because this data isn't stored in a file but in the pack description itself its not (currently) persisted in my implementation.
> 
> Yes, you just discovered the hard way that the DfsPackDescription
> matters to the DFS backend. It wants the information it stores there
> to come back to it.

:-)

> But my original idea for DFS backend was to encode the DfsPackDescription
> data into the filename, and parse it back out when listing the packs
> of the repository. Unfortunately this might not be possible if you
> cannot rename a file, as some of the data arrives too late.

Yes, I found that out too :-)

However I found when the commitPack is called the info is there, so I write out a surrogate file with the data encoded in it. 

The only real question is how much is needed; this is the first time I've needed anything at currently it works with only objectCount set.

I imagine that fileSize and lastModified would be useful to enable the correct priority sorting to work but I'm not sure whether the statistics are relevant outside of a DfsGarbageCollect result. I'm not sure about deltaCount. 

The question is what subset is strictly necessary? Perhaps unnecessary fields (if any) could be annotated with "transient". 

Alex