So, to pick this topic up again, can we get an open punchlist of things that the mercurial community (and project leader) believes is "missing" for the largefiles extension? E.g, what is missing for it to be accepted into mercurial?<br>
<br>The main repository is living here: <a href="https://developers.kilnhg.com/Repo/Kiln/largefiles/largefiles">https://developers.kilnhg.com/Repo/Kiln/largefiles/largefiles</a><br><br>(there's also a branch with some compatibility stuff that's useful for Kiln users, but that is not so relevant here).<br>
<br>Cheers,<br>Na'Tosha<br><br><div class="gmail_quote">2011/8/15 Greg Ward <span dir="ltr"><<a href="mailto:greg-hg@gerg.ca">greg-hg@gerg.ca</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Sun, Aug 14, 2011 at 6:24 PM, Andrew Pritchard <<a href="mailto:awpritchard@gmail.com">awpritchard@gmail.com</a>> wrote:<br>
>> Idea: how hard would it be to add the standin prefix dir to the wire<br>
>> protocol? It should only have to be sent once per conversation.<br>
><br>
> That would actually not be particularly difficult, and it could easily<br>
> be stored in '.hg/largefiles/standins' or the like.  The<br>
> largefiles-kiln branch already has code for dealing with per-repo<br>
> prefixes, to make kbfiles repositories continue to work, but it<br>
> currently just checks for the existence of ''.hg/store/data/.hglf/*.i"<br>
> or ".kbf/*.i".<br>
<br>
</div>So users of kbfiles have the same problem as users of bfiles? I.e.<br>
switching to largefiles would be easy if largefiles transparently<br>
recognized the old standin dir, but disruptive if we force them to<br>
convert with a filemap?<br>
<div class="im"><br>
> This would still make hosting providers' jobs a bit<br>
> harder, since they would have to keep track of the prefix in order to<br>
> handle largefiles separately.<br>
<br>
</div>If they choose to. IMHO if a hosting provider chooses to say "we<br>
support largefiles, but *only* with the canonical default .hglf [or<br>
whatever we settle on] prefix", that's entirely reasonable. bfiles and<br>
kbfiles should be viewed as prototypes.<br>
<div class="im"><br>
> Just brainstorming here, but currently the value of the 'lfilestore'<br>
> capability carries no meaning: I set it arbitrarily to 'serve' to<br>
> leave it open to future versions of the protocol or alternative ways<br>
> of providing a store, but it could be used as the prefix, as in<br>
> 'lfilestore=.hglf'.  This would be a bit weird in that the<br>
> capabilities reported by the server could vary per repository, and it<br>
> also doesn't solve the problem of identifying the prefix when pushing<br>
> largefiles changesets to a repository that currently has none.<br>
<br>
</div>That does seem weird.<br>
<div class="im"><br>
> Abandoning that line of thought almost entirely, it could use the<br>
> pushkey mechanism, adding no new wireproto commands and even taking<br>
> advantage of the warn-on-already-existing key behavior in the case of<br>
> a repository that already has largefiles.<br>
<br>
</div>Yeah, that sounds sensible.<br>
<div class="im"><br>
> There could be some weirdness if two developers simultaneously add<br>
> largefiles to a previously-vanilla repository and try to push them,<br>
> but as long as new largefiles repositories always use a specific<br>
> prefix, that shouldn't cause any problems.<br>
<br>
</div>I don't think we should expose any way to use a non-default standin<br>
prefix. .hgbfiles/ and .hgkbf/ are legacy prefixes that we should<br>
support for the convenience of users, but there is no reason to create<br>
a new largefiles repo using those prefixes. One ring to rule them all,<br>
and all that.<br>
<font color="#888888"><br>
Greg<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Mercurial-devel mailing list<br>
<a href="mailto:Mercurial-devel@selenic.com">Mercurial-devel@selenic.com</a><br>
<a href="http://selenic.com/mailman/listinfo/mercurial-devel" target="_blank">http://selenic.com/mailman/listinfo/mercurial-devel</a><br>
</div></div></blockquote></div><br><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>