<div dir="ltr">Hi Chris,<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 8:38 AM, Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span> wrote:<br>
<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"><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?</blockquote><div> </div><div>Cuz it's where one can look for versions when working off line. For some package-cache is an in-your-face place (me for example).</div><div> </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>
Y'all keep coming up with these "non-problems" and then "solving" them<br>
with "branches". Its crazy.<br>
<br>
Another thing I was never clear about -- the output of your<br>
patch-utilities -- does it produce a NEW version with the old one as<br>
an ancestor (as it should!)? Or are you actually modifying the<br>
original but keeping the same UUID, same author, same version? I<br>
think destroying the original is very bad idea -- but I can see that,<br>
if you are, why it would make you want to employ "branches" to bail<br>
you out... OMG, hacking MC with even more unnecessary precedents?!<br>
(shudder) Please tell me I'm wrong! Eliot, there's a _reason_<br>
something is a *Version* -- it should never ever be modified.<br></blockquote><div><br></div><div>It creates a new version:</div><div><br></div><div><span style="white-space:pre"> </span>^MCVersion</div><div><span class="" style="white-space:pre"> </span>package: version package</div>
<div><span class="" style="white-space:pre"> </span>info: (ancestry</div><div><span class="" style="white-space:pre"> </span>infoWithName: version info name</div><div><span class="" style="white-space:pre"> </span>message:<span class="" style="white-space:pre"> </span>version info name,</div>
<div><span class="" style="white-space:pre"> </span>' patched for Spur by ',</div><div><span class="" style="white-space:pre"> </span>(CCodeGenerator shortMonticelloDescriptionForClass: self class),</div>
<div><span class="" style="white-space:pre"> </span>'\\' withCRs,</div><div><span class="" style="white-space:pre"> </span>version info message)</div><div><span class="" style="white-space:pre"> </span>snapshot: snapshot</div>
<div><span class="" style="white-space:pre"> </span>dependencies: {} "punt on computing dependencies; there are't any so far"</div><div> </div><div>So it has its own UUID etc.</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">
<div class=""><br>
> If we go with branches, which I'm finally accepting is the only sane way to<br>
> go, we'll know they're both for trunk, and their duals are<br>
> "Collections.spur-cmm.521" and "Collections.spur-eem.523". So I'll modify<br>
> the bootstrap to produce branched packages, and modify the update process to<br>
> upload these to trunk. We can nuke the spur repository. It was a useful<br>
> learning experiment. We can nuke the primary/secondary repository support.<br>
> It was an uninformed attempt at a fix.<br>
><br>
> Agreed?<br>
<br>
</div>Why not tell me what you learned so I can learn too? I really want to<br>
know why the separate spur repository was so bad it has you wanting to<br>
hack version-names so they can act as a string-filter "partition" in<br>
one big slow repository instead of simply using two repositories (two<br>
ecosystems). I'm not seeing any sanity in that..<br></blockquote><div><br></div><div>OK.</div><div><br></div><div>First, making the update scheme handle two repositories is non-trivial. The code needs rewriting, and that is too complex for me.</div>
<div>Second, the non-branch scheme is at best confusing or at worst clashes in places like the package cache.</div><div>Third, the branch scheme does all we need already, because it was my misunderstanding that a branch name would prevent me removing the branch name once we're ready to switch to spur. That's not the case. The ancestry apparently doesn't include the branch name.</div>
<div><br></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">And no one but me has acknowledged the costs of branches. Are you<br>
actually "weighing the cost" or do you think branches are "free"?<br>
<div class=""><br>
>> So, the value of branch-tag seems really really<br>
>> low -- practically non-existent. Please enlighten me, what use-case<br>
>> do branches save the day and pay for their forever-cost?<br>
><br>
> I have to say they're hugely valuable. They've allowed me to develop Cog<br>
> (in VMMaker.oscog). They provide me a way of placing branched versions of<br>
> Kernel, Collections and System alongside their trunk siblings.<br>
<br>
</div>Again, you stated the obvious "what" it does, above, but not _why_<br>
it's valuable, and why it couldn't be done another way.. Sad.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>