On 18.06.2014, at 05:05, 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. 

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

> 
>> 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.
> 
> 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. Even if Eliot decides to open a separate inbox for Spur, it would *still* be a good idea to use proper branches. 

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

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

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.

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

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

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?

- Bert -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140618/52f065e0/smime.bin