[PATCH] largefiles: makes verify to work on local content by default (issue4242) (BC)

[Piotr Listkiewicz]

I still would like to resolve this, but i need Your opinion how verify
should behave like I decribed it in pre previous message.

2016-03-26 12:47 GMT+01:00 Piotr Listkiewicz <piotr.listkiewicz at gmail.com>:

> I still want to do this issue, i would be glad for suggestions what verify
> --lfc should do as described in previous mail
>
> 2016-03-17 20:45 GMT+01:00 Sean Farley <sean at farley.io>:
>
>>
>> Piotr Listkiewicz <piotr.listkiewicz at gmail.com> writes:
>>
>> >>
>> >> I re-read the code, and it seems you get the point. Perhaps "local"
>> has two
>> >> different meanings:
>> >>  a) a repository alongside the current working directory
>> >>  b) repositories that are stored in local filesystem (includes (a))
>> >> New "--remote" options switches (a), and "--lfc" seems to work only for
>> >> (b).
>> >> So "--lfc" (without --remote) should always work. On the other hand,
>> >> "--lfc --remote" won't work if the peer repository is stored remotely.
>> >> Should we raise error in that case? I don't know...
>> >
>> >
>> > I checked this once again, and before this patch --lfc works even
>> weirder
>> > than i thought.  So how --lfc works depends on how value
>> > default/default-push in hgrc is specified. The cases are:
>> >
>> > 1) there is no default or is sth wrong with default
>> > --lfc works as expected, checks locally existence and content
>> > in code this is localrepo with remote set to repo we invoke the command
>> >
>> > 2) default is pointing at repository on local file system (default
>> starts
>> > with file:")
>> >
>> > --lfc checks file existence and content but on the repository pointed by
>> > default(not on the repository the command was invoked)
>> >
>> > in code this is localrepo with remote set to repo pointed by default
>> >
>> > 3) default is pointing by http on some place on web
>> >
>> > --lfc checks file existence but not content.
>> >
>> > in code this is wirestore with remote set to repo pointed by default
>> >
>> > What is more, --large and --lfa also choose repository to check in this
>> > strange way. Option --lfc by design wasn't prepared to work on remote
>> > repository, because authors thought that it was too expensive to enable
>> it.
>> > For now there are several different paths to resolve it:
>> >
>> > 1) makes --large, --lfa, --lfc do checks locally by default, with
>> --remote
>> > checks on remote and we accept that --lfc is expensive operation on
>> remote
>> > repo. In my view that would be what user expects
>> >
>> > 2) makes --large, --lfa do checks by default, with --remote checks on
>> > remote(with remote we mean outside of repository, it can be on the same
>> > machine). Option --lfc always would be doing local checks, with
>> --remote it
>> > would abort msg  "cannot --lfc and --remote at the same time".
>> >
>> > However from the point of current implementation it cant be handled so
>> > easily because wirestore doesn't do any content check, localstore is
>> doing
>> > no matter if remote is the same repository or other repository on the
>> same
>> > machine.
>> >
>> > 3) makes --large, --lfa, --lfc do checks only locally
>> >
>> > In my view current behaviour is so weird that choosing any alternative
>> > would be step in good direction. What do you suggest?
>>
>> Mads, have you seen this?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160411/77612b81/attachment.html>