<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'm not sure if there's a lot of teaching value in this, but maybe consider replacing some of the os.path.* code in largefiles with the vfs layer. There might be enough there that you can see how it looks up files in the store, and so forth. If nothing else, it will give you something to do when looking at the code.</span><br style="font-size:12.8px"><span style="font-size:12.8px"> </span><a href="https://www.mercurial-scm.org/wiki/WindowsUTF8Plan" rel="noreferrer" target="_blank" style="font-size:12.8px">https://www.mercurial-scm.org/wiki/WindowsUTF8Plan</a></blockquote><div><br></div><div>I would like to do it, but i need guidance. </div><div><br></div><div>In function lfutil.storepath(<a href="https://selenic.com/hg/file/e00e57d83653/hgext/largefiles/lfutil.py#l175">https://selenic.com/hg/file/e00e57d83653/hgext/largefiles/lfutil.py#l175</a>) is returned path to the largefile directory in .hg, it is used nearly everywhere else as base path.</div><div><br></div><div>This method could be refactored to return vfs object - which would be used instead of invoking for example util.makedirs, but i have no idea how should i do it properly( i also dont understand why this function returns repo.vfs.reljoin(repo.sharedpath, longname, hash) or repo.join(longname, hash) - i just dont get the difference). </div><div><br></div><div>I would appreciate any hints or guidance.</div><div><br></div><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">This is more advanced, but would be nice to have in some form:</span><br style="font-size:12.8px"><span style="font-size:12.8px"> </span><a href="https://bz.mercurial-scm.org/show_bug.cgi?id=4242" rel="noreferrer" target="_blank" style="font-size:12.8px">https://bz.mercurial-scm.org/show_bug.cgi?id=4242</a><br style="font-size:12.8px"><span style="font-size:12.8px">(My recollection of this is that it wants to verify the files upstream on the default path instead of touching anything locally. I think I end up using '--config paths.default=' to force it to verify locally.)</span></blockquote><div><br></div><div>I sent patch to it, can you take a look and do code-review?</div><div><br></div><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"><br><span style="font-size:12.8px">Is there some specific area you are wondering about? Maybe look for commits that start with 'largefiles:'. I fixed a series of bugs about a year ago or so, and tried to leave enough in the commit comment to explain what was wrong or how something works.</span></blockquote><div><br></div><div>Now im trying to understand how largefile works in big picture(and inner workings of it) , so i have no specific area at this moment. </div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-01 4:05 GMT+01:00 Matt Harbison <span dir="ltr"><<a href="mailto:mharbison72@gmail.com" target="_blank">mharbison72@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 29 Feb 2016 09:57:21 -0500, Piotr Listkiewicz <<a href="mailto:piotr.listkiewicz@gmail.com" target="_blank">piotr.listkiewicz@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
I am Piotr Listkiewicz (nicknamed liscju), Computer Science student from<br>
Cracow in Poland, maybe some of you remembers me from 3.6 Sprint in London.<br>
<br>
I am interested in working on "Allow largefiles to be at a different<br>
location" project, but i need guidance.<br>
<br>
First of all ,are there any easy bugs that you would recommend for the<br>
newcomer for largefile extension for familiarizing myself with the source<br>
code?<br>
</blockquote>
<br></span>
I don't think there are any easy bugs left. The wrapping done by the extension can make things surprisingly complicated. There are a few additional archived (hidden) largefile bugs on bz, but I'm not sure they are easy either.<br>
<br>
I'm not sure if there's a lot of teaching value in this, but maybe consider replacing some of the os.path.* code in largefiles with the vfs layer. There might be enough there that you can see how it looks up files in the store, and so forth. If nothing else, it will give you something to do when looking at the code.<br>
<br>
<a href="https://www.mercurial-scm.org/wiki/WindowsUTF8Plan" rel="noreferrer" target="_blank">https://www.mercurial-scm.org/wiki/WindowsUTF8Plan</a><br>
<br>
This is more advanced, but would be nice to have in some form:<br>
<br>
<a href="https://bz.mercurial-scm.org/show_bug.cgi?id=4242" rel="noreferrer" target="_blank">https://bz.mercurial-scm.org/show_bug.cgi?id=4242</a><br>
<br>
(My recollection of this is that it wants to verify the files upstream on the default path instead of touching anything locally. I think I end up using '--config paths.default=' to force it to verify locally.)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Secondly , are there any other documents that didn't mentioned at<br>
<a href="https://www.mercurial-scm.org/wiki/SummerOfCode/Ideas2016" rel="noreferrer" target="_blank">https://www.mercurial-scm.org/wiki/SummerOfCode/Ideas2016</a> that would be<br>
helpful for familiarizing myself with largefile and project subject in<br>
general?<br>
</blockquote>
<br></span>
The wiki is pretty good at a high level:<br>
<br>
<a href="https://www.mercurial-scm.org/wiki/LargefilesExtension" rel="noreferrer" target="_blank">https://www.mercurial-scm.org/wiki/LargefilesExtension</a><br>
<br>
The "magic" of this extension is mostly that it patches up the matcher object and hands off to core Mercurial to do most of the work, in most situations. e.g. if the user does `hg add --large foo`, the largefiles add() code changes the matcher to contain '.hglf/foo', remove 'foo', and then passes it into the core add() function. (All without touching normal file references, if any, of course.)<br>
<br>
Is there some specific area you are wondering about? Maybe look for commits that start with 'largefiles:'. I fixed a series of bugs about a year ago or so, and tried to leave enough in the commit comment to explain what was wrong or how something works.<br>
<br>
Unfortunately, I don't know anything about the wire protocol to help you there.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would be interested in any piece of advice what should i do, how to start<br>
working on the project and all relevant information as well.<br>
</blockquote>
</div></div></blockquote></div><br></div>