[PATCH 01 of 17 V2] largefiles: rename lfutil to storeutil

[Matt Harbison]

On Thu, 12 May 2016 06:20:23 -0400, liscju <piotr.listkiewicz at gmail.com>  
wrote:

> # HG changeset patch
> # User liscju <piotr.listkiewicz at gmail.com>
> # Date 1462488595 -7200
> #      Fri May 06 00:49:55 2016 +0200
> # Node ID 6606554248eaeffc7dc43b62f3b9d8128b86b9b6
> # Parent  c641b8dfb98c2ade6995ba3aa341fe4d7b154827
> largefiles: rename lfutil to storeutil
>
> lfutil should be used as higher level module by lfcommands and
> overrides. storeutil should have utilities to deal with store
> and be lower level module. This separation will be helpful in
> resolving cycle dependencies.
>

> diff -r c641b8dfb98c -r 6606554248ea hgext/largefiles/storeutil.py
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/hgext/largefiles/storeutil.py	Fri May 06 00:49:55 2016 +0200

You need diff.git = True in your config to get the rename properly  
exported here.

I'm wondering about this rename in general.  There seem to be utility  
functions unrelated to the store in the current lfutil, which get swept up  
in the rename- standin related things, matchers and so forth.  And then  
lfutil gets reintroduced in the next patch.  Would it be better to copy  
lfutil.py to storeutil.py, and then delete the things in each that belong  
to the other?  This way, you don't have to move the stuff that isn't store  
related back.

Possibly part of the issue is when I see a reference to "store" in the  
name, I think of the .hg/largefiles directory, and/or the global user  
cache.  Aside from the cycle checker yelling, it isn't clear to me where I  
should add a new utility method.  Could the whole issue be avoided by  
simply moving basestore stuff from patch #2 into lfutil?  (Even though it  
isn't really a utility.)  Or maybe just move the handful of path related  
methods now in lfutil to storeutil?