[squeak-dev] Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

Eliot Miranda eliot.miranda at gmail.com
Thu Jun 19 02:22:19 UTC 2014


On Wed, Jun 18, 2014 at 9:09 AM, Chris Muller <asqueaker at gmail.com> wrote:

> >>> The basic unit we deal with in MC is the MCZ file (or MC version if
> it's not in a file). With proper branching, this basic unit *carries the
> information* of which branch it's from.
> >>
> >> Agreed.  As, it does, its full ancestry.
> >
> > Nope. The ancestry does not have a slot to tell which branch each
> version is from. That info is *intended* to be taken from the version name.
> >
> > Or are you seriously suggesting to parse comments to tell if a version
> is from a branch? It's *impossible* to tell from just looking at the
> ancestry - these packages do share a common ancestry with Trunk packages,
> that's the whole point of branching instead of creating new packages.
>
> Maybe it would help if you identified what use-case you're talking
> about where branches can save someone so much effort?  I was using the
> use-case of setting up a new image as my example, and how a separate
> repository makes branch-tagging unnecessary.  What use-case are you
> referring to and how often does that use-case occur?
>
> > The only other way I could think of (I am trying hard, you see) would be
> if you maintained a list of version infos that are "known" to be the
> "roots" of that branch.
>
> Yes!  By starting them off in a separate repository dedicated to that
> branch, the contents of that repository _is_ your list.  You wouldn't
> necessarily have to include all the ancestors but, even if you did,
> every use-case I can think of, from then on, is only concerned with
> the _latest_ versions, which will be for that branch..  No problem!
>
> >  Then by parsing the ancestry you could see if any of these roots are in
> the ancestry. But besides being expensive to examine, that information
> necessarily is external to the version itself. It won't be transmitted when
> you send versions elsewhere. In particular, a trunk image won't know that
> these versions are special. With a branch name attached, it would.
>
> Hey, at least you're entertaining some creative ideas, thank you!
> This is important because I think diving into branches as a community
> could have long-term repercussions..
>
> >>> By only putting a version in a different repo, the branch info is not
> attached to the version itself, it cannot be acted
> >> upon properly without utmost care by the user. Which *did* lead to a
> >> version getting submitted to the wrong repo.
> >>
> >> What do you mean by "wrong repo"?  Someone submitted something to the
> >> Inbox for Spur, _because_ there was no SpurInbox repository for him to
> >> put it.  If there were, then that's where it would have been saved --
> >> because anyone developing Spur will have set up their Monticello UI
> >> with the Spur repositories, making it very hard to accidently commit
> >> to the wrong repository.
>
> Why did you ignore the above, its a main point..?
>
> >> If we want to clone all the abilities of Trunk _including_ the Inbox
> >> submission, then we gotta give Eliot all the same resources, e.g., a
> >> SpurInbox too.
> >
> > Note that I did not talk about having different repos.
>
> Okay, so let's talk about it!  I had thought you said they were
> problematic and insufficient.  Why?
>
> > Even if Eliot decides to open a separate inbox for Spur, it would
> *still* be a good idea to use proper branches.
>
> Why?
>
> >>> And there is *no way to tell*, unless stuff randomly breaking when you
> load that version is considered fine.
> >>
> >> C'mon Bert, even in a single-repository ecosystem, I'm not buying
> >> that.  This whole event is pretty low-impact, wouldn't you say?
> >
> > No. Not at all low-impact if you want to automate things.
>
> Exactly the opposite.  Use of "branches" are what causes packages to
> be excluded from the new-and-improved club.  The MC method history
> function, for example, which has been available for going on a year
> now -- unfortunately is unavailable to projects that chose to use
> branches because that implicit function was hacked back into FileBased
> only.
>
> getimothy is seeing performance issues and timeouts, hmm, I wonder
> why?  I suspect it's because there are so many files in one
> repository, it's just taking longer and longer to read that directory.
> Combining multiple branches into one repository exacerbates that
> problem.
>
> >> How
> >> often do you go loading an Inbox package without saving your image
> >> first?  Plus, there _is_ a way to tell -- if something is worth
> >> documenting in a version-name, then worth documenting in the
> >> version-comments.  We're talking about 2-4 clicks to check the
> >> ancestry.
> >
> > No, we're talking about parsing that info out of hundreds of files that
> need to be downloaded from a remote server, vs. checking just their file
> names. I get the impression you're intentionally avoiding this fact.
>
> Please, what use-case are you talking about here?
>
> > Actually, I don't get this at all. You have been the one wanting to make
> the MC version name encoding explicit. Which turned out to be a good idea,
> code became simpler and more readable. And *now* you're suggesting to bury
> vital information in the comment, instead of the existing, documented field
> in MCVersionName? Sorry, you lost me there.
>
> I'm suggesting that the number of times one _needs_ to know exactly
> all which versions are for one branch vs. the other is so rare, it's
> not worth incurring the forever-cost of "branches".  I really dying to
> know what use-case has you wanting to do that for "hundreds of files",
> on a regular basis?  And why a separate repository woudln't alleviate
> the pain even IF it's needed on a regular basis?
>
> >> Copying select versions between the two could be set up to be automatic
> or
> >> deliberate, as needed, but the key is that it's using **existing** MC
> >> code and infrastructure to do that.
> >
> > In contrast to the *existing* branch support?
>
> Yes because branches are currently NOT supported for anything but
> FileBased, and whose function interferes with the simplicity of the
> tools and the abilities of the other MCRepository types.
>
> >> What do you think of Eliot's recently introduced preference,
> >> "Secondary Update URL"?
> >
> > I actually could have used that, two years ago, when I set up an update
> mechanism for VPRI's Frank project. I instead had to write considerable
> code to allow using two update streams at once.
>
> My whole question about that was, "Was it a good trade-off?"  Sure,
> it's a useful function for that moment in history, but you ignored the
> *forever-cost* (actually even trimmed it!).
>
> >>> With the evidence we have available now we can conclude that relying
> on separate repos is not enough. Being explicit about the branch is a Good
> Idea.
> >>
> >> We should collect evidence when its set up properly -- the same as
> trunk.
> >>
> >> PS -- instead of just responding with "why we can't", I really hope
> >> you'll give this proposal a fair shake.
> >
> > See above - I am trying to imagine how this could work reliably without
> real branching. I can't.
>
> Thanks for your perseverence -- we've put in this much effort, I hope
> we'll find a consensus.
>
> > Leaving aside how many repos Eliot wants to use: being able to tell from
> the MCZ itself that it's from a different branch is a Good Idea. Think your
> local package cache. Think sending versions by email. Etc. Let's make this
> concrete: You're looking at your package cache - how exactly do you tell a
> version is from the spur branch or trunk? How would a script tell?
>
> I guess I feel that the responsibility for that should not be put on
> MCVersion.  MCVersion should be concerned with the stuff it manages --
> it's Snapshot and below (Definitions, etc.).  We shouldn't inject a
> hierarchy into its name just so it will happen to sort conveniently in
> some tool way up there..
>
> Anything concerned with what Versions belong with what branch should
> managed by the higher-level mechanisms that already manage Versions --
> Repositories and Configurations.
>
> 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.

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?




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

If there is still a problem it is that (IIRC) I can't yet use the tools to
compare a branched package with an unbranched package.  The diff tools say
that everything's changed (I think).  Am I right?


sorry for all this noise...
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140618/0a4a9415/attachment-0001.htm


More information about the Squeak-dev mailing list