2011/10/14 Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com">justin.holewinski@gmail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Wed, Oct 12, 2011 at 1:05 PM, Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

I'm excited for the new largefiles extension, and I have been trying it out on some local test repositories.  I realize the extension (in its "official" form) is very new and subject to change, but I have a question on how the large files are (or are going to be) stored on the server.<div>



<br></div><div>Let's say I have two local repositories S and C.  S represents the "server" repository, and C represents a client clone.  If I add large files to C and push to S, the large files appear to be stored in $HOME/.largefiles, not in the .hg directory for S.</div>
</blockquote></div></div></div></blockquote><div><br>I believe this makes sense, based on the current implementation. <br></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>  It looks like S just contains hashes for the files, which makes sense.</div>
</blockquote></div></div></div></blockquote><div><br>This is correct -- the hashes are sitting in S/.hglf -- correct?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>  Incidentally, will there be a config option for this, for users that wish to sandbox all hg-related files in a separate directory?</div>
</blockquote></div></div></div></blockquote><div><br>Every large-files enabled repo will have it's own set of standins maintained in repo/.hglf -- I don't see any reason why this should be able to be moved out of the repository because it is repo-specific.  Also the standins are very small text files, so why do they need to be elsewhere?<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



<div></div><div>Now, let's say I create a new repository accessible over SSH, called S2.  If I push C to S2, the largefiles seem to be stored in *both* $HOME/.largefiles (in the SSH account) and the .hg directory for S2.  Things are getting a bit inconsistent.</div>
</blockquote></div></div></div></blockquote><div><br>That does sound inconsistent -- to me, anyway.  There shouldn't be any largefiles in S2/.hg -- there should only be the textfiles with the SHA1 sums in S2/.hglf -- is the S2/.hglf directory there?<br>
 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



<div></div><div>I have not tested HTTP/HTTPS, but what is the expected behavior in this case?  There may not be a writable home directory in this case.</div><div><br></div><div><br></div><div>More specifically, what are the planned methods for storing large files on mercurial servers?</div>

</blockquote><div><br></div></div></div><div>Ping?  Any comment from the largefiles devs on the planned server storage model?</div></div></blockquote><div><br>I'm not really sure we have a concrete plan yet.  This extension (at least in this form) is very new.<br>
<br>Some of us are expecting to use largefiles with Kiln, which just implements the server-side stuff already.  Some people will be migrating from the old bfiles extension, which means they already have a central share set up somewhere (but I assume some conversion will be necessary).  Greg is preparing a way for users to migrate from bfiles to largefiles, so he might have some idea on this.<br>
<br>The built-in serving ability of largefiles was developed by the team at FogCreek, so hopefully one of them can reply with what their vision was.<br><br>My initial thought is that:<br><br>The $HOME/.largefiles cache should be configurable server-side, if it is not already<br>
Each repo should only contain the hashes in repo/.hglf -- when largefiles are uploaded, they should probably all go directly to the cache.<br><br>Cheers,<br>Na'Tosha<br></div></div><br clear="all"><br>-- <br><div><div>
<span style="color: rgb(153, 153, 153);"><b>Na'Tosha Bard</b></span></div><div><font color="#999999">Build & Infrastructure Developer | Unity Technologies</font></div><div><font color="#999999"><br></font></div><div>
<font color="#999999"><b>E-Mail:</b> <a href="mailto:natosha@unity3d.com" target="_blank">natosha@unity3d.com</a></font></div><div><font color="#999999"><b>Skype:</b> natosha.bard</font></div></div><br>