<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:856576307;
mso-list-type:hybrid;
mso-list-template-ids:2019971882 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal>One of the problems that is regularly mentioned about distributed
version control systems has to do with repository size when it comes to
handling a lot of “binary” files in the repo. Coming from a games
development background where assets (images, models, video, sound) can easily end
up using several tens of gigabytes at the tip and maybe hundreds in the
history, I most certainly understand that argument. And while I really would
like to get hold of some of the features offered by DVCS, this is a factor
holding me back.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>So, I was thinking that perhaps it would be possible to replace
historical content with pointers to a “master” repository. Most of
the time you don’t need to diff against or view old versions of binaries,
but you do need the history intact, and it’s not uncommon that you need
to recreate old builds or patch previous releases. So, I would propose two
features:<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'>
</span></span><![endif]>The ability to tell “clone” not to copy
along large revisions (other than those at the tip) of files that aren’t
stored in a “diff”-style format (which I assume binaries aren’t
anyway, since they usually diff very badly). Instead it stores a pointer to the
original repo, allowing a user to fetch it only when it’s needed, which
would be rarely. I admit this goes a bit against the distributed mentality, but
it could be an optional feature for those who can maintain a central repo
without size constraints. The option would still be there to clone completely
of course. Oh, and for local clones I guess this would normally be pointless,
since things are hard linked anyway. So it’d be useful only for remote
clones.<o:p></o:p></p>
<p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'>
</span></span><![endif]>The ability to “purge” local large binaries
from a clone, replacing them with pointers to the original parent repo. This
would be useful if you’ve done a lot of history browsing, or if you’ve
been updating the repo for a long time, getting new tip versions of those
binaries, building up a lot of payload on your local repo.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>I haven’t looked into the repo data structure enough
to know if this would blow up the general model anywhere, especially when it
comes to repo integrity checking and version hashing, but I’m sure there
are those of you who have and that you’ll let me know if I’m completely
lost here. Anyway, this is a common model even for centralized version control
tools that handle large assets, only they allow an admin to back up old revisions
to tape. Anyone asking for that revision would get a message about the file
being offline that they could bring to an administrator. Something similar
could be done for Hg, allowing a user to get the internet connection up in
order to fetch the missing files.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Cheers<o:p></o:p></p>
<p class=MsoNormal>/axl<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>