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

Piotr Listkiewicz piotr.listkiewicz at gmail.com
Sun May 15 16:52:40 EDT 2016


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


You are right, thanks for a tip


> 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.



> Could the whole issue be avoided by simply moving basestore stuff from
> patch #2 into lfutil?  (Even though it isn't really a utility.)


Simple moving _openstore from basestore to lfutil doesn't work, because
lfutil is used by localstore and remotestore. For now i don't see other
solution than extracting other module from lfutil or introducing new
module.

lfutil keeps functions that in general belongs to the following groups:
1. moving file from/to store/cache (store_utils)
    * for example storepath, findstorepath, copyfromcache
2. standins utilities (stdin_utils)
    * for example splitstandin, updatestandinsbymatch,
3. dirstate utilities (dirstate_utils)
    * for example openlfdirstate, largefilesdirstate
4. network utilities
    * for example storeprotonotcapable, httpsendfile
5. Others that should stay in lfutil
    * for example automatedcommithook, getstatuswriter

Three first utilities groups has dependencies like this:

store_utils <--uses-- standins_utils <--uses-- dirstate_utils

Store classes uses following groups from lfutil:
- basestore uses store utilities and standins utilities(not counting things
needed for _openstore)
- remotestore uses network utilities and store utilities
- wirestore uses network utilities

Network utilities can be moved from lfutil to remotestore. After this
*store classes use store utilities and standins utilities.

If we move store utilities and standins utilities from lfutil to the other
module which won't have any dependency on the other module from largefiles,
then we should be able to move _openstore to lfutil without any cycle
imoprt.

The options are following:
1) Moving store utils and standin utils to separate module
2) Moving store utils, standin utils and dirstate utils to separate modules

I have no idea which solution is better and how the new module should be
named. Any of those solution makes lfutil significantly smaller but if we
move store utils, standin utils and dirstate utils the difference between
this patch that renames lfutil and a new solution moving things from lfutil
is pretty small.

I need a guidance what should i do.


2016-05-13 3:32 GMT+02:00 Matt Harbison <mharbison72 at gmail.com>:

> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160515/b622cef5/attachment.html>


More information about the Mercurial-devel mailing list