<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">I re-read the code, and it seems you get the point. Perhaps "local" has two<br></span><span style="font-size:12.8px">different meanings:</span><br style="font-size:12.8px"><span style="font-size:12.8px"> a) a repository alongside the current working directory<br></span><span style="font-size:12.8px"> b) repositories that are stored in local filesystem (includes (a))</span><br style="font-size:12.8px"><span style="font-size:12.8px">New "--remote" options switches (a), and "--lfc" seems to work only for (b).</span><br style="font-size:12.8px"><span style="font-size:12.8px">So "--lfc" (without --remote) should always work. On the other hand,<br></span><span style="font-size:12.8px">"--lfc --remote" won't work if the peer repository is stored remotely.<br></span><span style="font-size:12.8px">Should we raise error in that case? I don't know...</span></blockquote><div><br></div><div>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:</div><div><br></div><div>1) there is no default or is sth wrong with default</div><div>--lfc works as expected, checks locally existence and content</div><div>in code this is localrepo with remote set to repo we invoke the command</div><div><br></div><div>2) default is pointing at repository on local file system (default starts with file:")</div><div><br></div><div>--lfc checks file existence and content but on the repository pointed by default(not on the repository the command was invoked)</div><div><br></div><div>in code this is localrepo with remote set to repo pointed by default</div><div><br></div><div>3) default is pointing by http on some place on web</div><div><br></div><div>--lfc checks file existence but not content.</div><div><br></div><div>in code this is wirestore with remote set to repo pointed by default</div><div><br></div><div>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:</div><div><br></div><div>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</div><div><br></div><div>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". </div><div><br></div><div>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.</div><div><br></div><div>3) makes --large, --lfa, --lfc do checks only locally</div><div><br></div><div>In my view current behaviour is so weird that choosing any alternative would be step in good direction. What do you suggest?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-14 14:15 GMT+01:00 Yuya Nishihara <span dir="ltr"><<a href="mailto:yuya@tcha.org" target="_blank">yuya@tcha.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 11 Mar 2016 13:56:56 +0100, Piotr Listkiewicz wrote:<br>
> > Hmm it looks for me like this is the other bug in largefile, this would<br>
> > mean that so far --lfc for remote repos didnt verify file contents but only<br>
> > existence.<br>
> > After applying this patch --lfc will use localstore.localstore which<br>
> > verifies contents correctly (not just existence) but for remote repos it<br>
> > will preserve current( for me it looks like bad) behaviour.<br>
><br>
> I checked this once again and I was totally wrong about remotestore and<br>
> "--lfc" and "--lfc --remote", Im sorry for that.<br>
><br>
> First of all i made mistake of not changing help, for verify --lfc should<br>
> be:<br>
> "verify largefile contents, not just existence" , without remote it will<br>
> check locally , with --remote it will check on remote server.<br>
><br>
> After this patch 'hg verify --lfc' (without --remote) will be using<br>
> localstore class (with self.remote object pointing to the same local<br>
> repository as self.repo). This means that all checking will be done locally<br>
> and checking file content will be working correctly(--large and --lfa also<br>
> works only locally by default).<br>
><br>
> As far as we concern local operations, everything is fine. Problem starts<br>
> with --remote - that is the old implementation of largefiles verify. I have<br>
> no idea how but it uses remotestore/wirestore object and connect to the<br>
> other server with them but still verifies things locally.<br>
> I have no idea how its working, maybe anybody have any suggestion?<br>
<br>
</span>I re-read the code, and it seems you get the point. Perhaps "local" has two<br>
different meanings:<br>
<br>
 a) a repository alongside the current working directory<br>
 b) repositories that are stored in local filesystem (includes (a))<br>
<br>
New "--remote" options switches (a), and "--lfc" seems to work only for (b).<br>
<br>
So "--lfc" (without --remote) should always work. On the other hand,<br>
"--lfc --remote" won't work if the peer repository is stored remotely.<br>
Should we raise error in that case? I don't know...<br>
</blockquote></div><br></div>