[PATCH 1 of 2 bfiles] Support pushing to HTTP stores

Adrian Buehlmann adrian at cadifra.com
Mon Jun 7 10:15:17 CDT 2010


On 07.06.2010 16:34, Benjamin Pollack wrote:
> 
> On Jun 6, 2010, at 5:12 AM, Adrian Buehlmann wrote:
> 
>> On 06.06.2010 00:29, Benjamin Pollack wrote:
>> [snip]
>>> The fncache code also currently only escapes files that are located in .hg/store, which has been frustrating for me on other occasions when I've wanted to reuse the logic for other locations. (E.g., Kiln caches annotation output, which required some copy-paste coding unless we wanted to store the annotation data in .hg/store). What are the feelings on abstracting that code so that it can provide names for files in other directories?
>>>
>>
>> Are you talking about store.hybridencode?
> 
> Yes.

The thing I'm afraid of is introducing errors.

The stack of encoding tricks in store.py is already near to insane level.

But I certainly see the potential use for things like bfiles and
possibly others.

On the other hand, it is an intimate detail of the stores.

Yikes. I'm really close to saying let's not touch store.py.

Would you agree to start providing some patches so we know what we are
talking about, at the risk that the work might be in vain (in case there
is no consensus to take the patches)?

>>
>> I'm getting a bit nervous when thinking about touching that. Maybe this
>> is a now really a case for having some code duplication.
>>
>> But maybe you can provide some gentle morphing patches to split out a
>> more generic subfunction?
>>
>> I'm wondering though what you want to do with the encodedir() step.
> 
> I absolutely may be underthinking things here, but it seems to me that encodedir would just need to be altered to know a) the paths it should accept, and b) what filenames to escape by adding/removing ".hg".  So, assuming you didn't use defaults, you might see
> 
> 	encodedir(path)
> 
> become
> 
> 	encodedir(path, root='data', protect=('.hg/', '.d/', '.i/',))
> 
> Alternatively, since the very-reusable parts of hybridencode are the SHA1 trick for long filenames, the aux/com/etc. substitution, and the case-folding compatibility, perhaps the right thing to do is to simply wrap those pieces into their own function, and have hybridencode call that.  I am perfectly happy to submit patches for either approach, but I'm not convinced yet which is correct/has the fewest side-effects.
> 

Do you need the encodedir step at all?

I got the impression you want a plain safe-for-Windows "short path"
encoding without the hard-coded "data" and "dh" directory stuff...

I think we need to start talking in patches.



More information about the Mercurial-devel mailing list