2014-06-19 17:38 GMT+02:00 Chris Muller <ma.chris.m at gmail.com>:

> >> 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?
>
> Y'all keep coming up with these "non-problems" and then "solving" them
> with "branches".  Its crazy.
>
>
Chris, what is a branch for you?
For some transition period, we have to maintain 2 parallel versions of some
packages (like Kernel)
- one for cog v3
- one for Spur
Doesn't that perfectly define a use case of branches?
The way we automate the process (or not) is not the problem, in all cases
we have to deliver two different artefacts.

Or is all your argumentation about naming conventions of a specific commit?
The name of a commit is not related to the type of repository. It's just an
ID.
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

So what is the name all about?
It's about guiding human when selecting/picking some specific package.
It's not perfect, but that's exactly what we currently have as well
established convention hardcoded in tool support.

The convention package.branch-author.version is just variant of above
convention.
And the tools already are aware of it, so again, what's the problem?
I don't see how it could be more a problem than package-author.version

What defines a branch is the ancestry.
The naming convention is just a helper to outline the intention (Hey, this
commit is intended for Spur image/Spur vm).

Using different repositories is also a possible alternate convention to
manage these branches.
But it ain't gonna work, because it's more complex to manage.
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.
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...
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.
If we accidentally load Kernel.cogv3 into spur instead of merging, no risk
to fail, the image will lock before we can commit anything.

For me, using branch naming convention is currently the best
efficiency/cost ratio since it costs almost nothing.

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).
We could dream of a better MC, but that's not what we have.

cheers

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140619/b894928a/attachment.htm