Hi Chris,


On Thu, Jun 19, 2014 at 8:38 AM, Chris Muller <ma.chris.m at gmail.com> wrote:

> >> I'm having trouble understanding the contexts of those examples.  What
> >> am I going to do with my package-cache that has branches saving the
> >> day for me?  Sending a version in an e-mail?  I would probably send a
> >> link to a config or a repository.  Even if I did send a MCZ Version in
> >> an email, the email would state what its for, any branch tag would be
> >> redundant..
> >>
> >> PS -- And, heck, even just the _contextual_ info (e.g., time and
> >> author) kinda gives it away anyway!  Frank already said if there's
> >> more than 2 branches going on simultaneously, that's a problem.  So,
> >> KNOWING what Eliot is working on these last months, if you see
> >> "Collections-cmm.521" and "Collections-eem.523", which one do you
> >> suppose is for Spur?
> >
> > That's the issue.  If we have two repositories, trunk & spur, then they
> will
> > be for Spur if they're in the spur repository and for trunk if they're in
> > the trunk repository.  If they're in your package-cache you haven't a
> hope
> > in hell of telling which is which, except if one has been patched by the
> > Spur bootstrap, in which case the checkin comment will say
> > "Collections-cmm.521 patches by SpurBootstrapMonticelloPackagePatcher
> > Cog-eem.158", which isn't very obvious.
>
> But you never answered --  What does the package-cache have to do with
> anything?  Why is it so important to even be a factor in this
> discussion?


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).


>
> Y'all keep coming up with these "non-problems" and then "solving" them
> with "branches".  Its crazy.
>
> Another thing I was never clear about -- the output of your
> patch-utilities -- does it produce a NEW version with the old one as
> an ancestor (as it should!)?  Or are you actually modifying the
> original but keeping the same UUID, same author, same version?  I
> think destroying the original is very bad idea -- but I can see that,
> if you are, why it would make you want to employ "branches" to bail
> you out...  OMG, hacking MC with even more unnecessary precedents?!
> (shudder) Please tell me I'm wrong!  Eliot, there's a _reason_
> something is a *Version* -- it should never ever be modified.
>

It creates a new version:

^MCVersion
package: version package
info: (ancestry
infoWithName: version info name
message: version info name,
' patched for Spur by ',
(CCodeGenerator shortMonticelloDescriptionForClass: self class),
'\\' withCRs,
version info message)
snapshot: snapshot
dependencies: {} "punt on computing dependencies; there are't any so far"

So it has its own UUID etc.


> > If we go with branches, which I'm finally accepting is the only sane way
> to
> > go, we'll know they're both for trunk, and their duals are
> > "Collections.spur-cmm.521" and "Collections.spur-eem.523".  So I'll
> modify
> > the bootstrap to produce branched packages, and modify the update
> process to
> > upload these to trunk.  We can nuke the spur repository.  It was a useful
> > learning experiment.  We can nuke the primary/secondary repository
> support.
> > It was an uninformed attempt at a fix.
> >
> > Agreed?
>
> Why not tell me what you learned so I can learn too?  I really want to
> know why the separate spur repository was so bad it has you wanting to
> hack version-names so they can act as a string-filter "partition" in
> one big slow repository instead of simply using two repositories (two
> ecosystems).  I'm not seeing any sanity in that..
>

OK.

First, making the update scheme handle two repositories is non-trivial.
 The code needs rewriting, and that is too complex for me.
Second, the non-branch scheme is at best confusing or at worst clashes in
places like the package cache.
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.


And no one but me has acknowledged the costs of branches.  Are you
> actually "weighing the cost" or do you think branches are "free"?
>
> >> So, the value of branch-tag seems really really
> >> low -- practically non-existent.  Please enlighten me, what use-case
> >> do branches save the day and pay for their forever-cost?
> >
> > I have to say they're hugely valuable.  They've allowed me to develop Cog
> > (in VMMaker.oscog).  They provide me a way of placing branched versions
> of
> > Kernel, Collections and System alongside their trunk siblings.
>
> Again, you stated the obvious "what" it does, above, but not _why_
> it's valuable, and why it couldn't be done another way..  Sad.
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140619/12bedd1b/attachment.htm