<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-19 17:38 GMT+02:00 Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">>> I'm having trouble understanding the contexts of those examples. What<br>
>> am I going to do with my package-cache that has branches saving the<br>
>> day for me? Sending a version in an e-mail? I would probably send a<br>
>> link to a config or a repository. Even if I did send a MCZ Version in<br>
>> an email, the email would state what its for, any branch tag would be<br>
>> redundant..<br>
>><br>
>> PS -- And, heck, even just the _contextual_ info (e.g., time and<br>
>> author) kinda gives it away anyway! Frank already said if there's<br>
>> more than 2 branches going on simultaneously, that's a problem. So,<br>
>> KNOWING what Eliot is working on these last months, if you see<br>
>> "Collections-cmm.521" and "Collections-eem.523", which one do you<br>
>> suppose is for Spur?<br>
><br>
> That's the issue. If we have two repositories, trunk & spur, then they will<br>
> be for Spur if they're in the spur repository and for trunk if they're in<br>
> the trunk repository. If they're in your package-cache you haven't a hope<br>
> in hell of telling which is which, except if one has been patched by the<br>
> Spur bootstrap, in which case the checkin comment will say<br>
> "Collections-cmm.521 patches by SpurBootstrapMonticelloPackagePatcher<br>
> Cog-eem.158", which isn't very obvious.<br>
<br>
</div>But you never answered -- What does the package-cache have to do with<br>
anything? Why is it so important to even be a factor in this<br>
discussion?<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Y'all keep coming up with these "non-problems" and then "solving" them<br>
with "branches". Its crazy.<br>
<br></blockquote><div><br></div><div>Chris, what is a branch for you?<br></div><div>For some transition period, we have to maintain 2 parallel versions of some packages (like Kernel)<br></div><div>- one for cog v3<br></div>
<div>- one for Spur<br></div><div>Doesn't that perfectly define a use case of branches?<br></div><div>The way we automate the process (or not) is not the problem, in all cases we have to deliver two different artefacts.<br>
</div><div><br></div><div>Or is all your argumentation about naming conventions of a specific commit?<br></div><div>The name of a commit is not related to the type of repository. It's just an ID.<br></div><div>If you insist, naming a commit 'Kernel-cmm.237' is not event necessary, we could just use the associated UUID as a name instead of package-author.version<br>
<div><br>So what is the name all about?</div><div>It's about guiding human when selecting/picking some specific package.<br></div>It's not perfect, but that's exactly what we currently have as well established convention hardcoded in tool support.<br>
<br></div><div>The convention package.branch-author.version is just variant of above convention.<br>And the tools already are aware of it, so again, what's the problem?<br></div><div>I don't see how it could be more a problem than package-author.version<br>
<br></div><div>What defines a branch is the ancestry.<br>The naming convention is just a helper to outline the intention (Hey, this commit is intended for Spur image/Spur vm).<br></div><div><br></div><div>Using different repositories is also a possible alternate convention to manage these branches.<br>
</div><div>But it ain't gonna work, because it's more complex to manage.<br></div><div>It means that a user merging some cog_v3_inbox/Kernel into a Kernel.spur should think of publishing the next commit into spur_inbox/Kernel.<br>
It's really easy to mess up, because all the responsibility to pick the right repository is on user shoulders, and we will mistake (I would, you would, we already did!). This may break our MCM update mechanism more than often...<br>
</div><div>With current branch convention support, we can't fail that easily. When we merge Kernel.cogv3 into a Kernel.spur, we still have a Kernel.spur working copy, and will publish a Kernel.spur by default, no risk to fail, this is automated.<br>
</div><div>If we accidentally load Kernel.cogv3 into spur instead of merging, no risk to fail, the image will lock before we can commit anything.<br></div><div><br>For me, using branch naming convention is currently the best efficiency/cost ratio since it costs almost nothing.<br>
<br></div><div>Of course, I agree, we could use more sophisticated backends (database), define a more sophisticated protocol for querying the backends (retrieve partial chunks rather than whole database contents), and take advantage of these in more sophisticated tools (for example drawing the history of branches and merges a la github).<br>
We could dream of a better MC, but that's not what we have.<br><br></div><div>cheers<br><br>Nicolas<br></div></div></div></div>