Smalltalk › Squeak › Squeak - Dev

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

35 messages Options

Bert Freudenberg

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

On 17.06.2014, at 21:41, Chris Muller <[hidden email]> wrote:

> **Eliot opened up his
> note suggesting** a new repository for spur. This whole thread
> could've ended there.. ;-)

Yes. But that lead directly to this discussion: We are trying to find a solution that *avoids* the problems caused by using separate repositories instead of proper branching.

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.

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. And there is *no way to tell*, unless stuff randomly breaking when you load that version is considered fine.

If Eliot had used proper branch names, this would not have happened. It's partly my fault because he asked me weeks ago if using multiple repos was the way to go and I did not foresee the problems this would cause. 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.

- Bert -

smime.p7s (5K) Download Attachment

Chris Muller-3

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

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

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

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

But that's moot anyway because we're discussing a correct clone of the
trunk ecosystem for Spur, one that includes a SpurInbox. 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.

> If Eliot had used proper branch names, this would not have happened. It's partly my fault because he asked me weeks ago if using multiple repos was the way to go and I did not foresee the problems this would cause.

By contrast, the "Branches" approach wants to stuff everything into
one big repository, and then employ some obscure, "implicit" filtering
mechanism, known as "branches", to serve as the partition between the
two projects. It's an additional concept whose implementation has
extended its tendrils into many classes in the form of redundant case
tests, and very much complicated the ability for tools to remain
simple and Repository-independent.

What do you think of Eliot's recently introduced preference,
"Secondary Update URL"? Consider that it will be empty for 99% of
Squeak users and, even for Eliot after he's long transitioned to Spur.
When will this ever be used or ripped out in the future? Probably
never to both questions. So I consider this as another example of
low-value infrastructure (but at least harmless unlike the branches).
I bet even Eliot would agree its hacky tacky, but it was considered a
necessary evil at the time because we couldn't / didn't think hard
enough for a way to avoid doing it. Separate repository anyone?

Fewer parts and concepts is better than more, isn't 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. I have zero ego about this
and I hope you do too.

Tobias Pape

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

there's only one trunk, there should be only one inbox.
branches is right.

--
Tobias Pape
sent from a mobile device

Am 18.06.2014 um 05:05 schrieb Chris Muller <[hidden email]>:

>> 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.
>
>> 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.
>
>> 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? 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.
>
> But that's moot anyway because we're discussing a correct clone of the
> trunk ecosystem for Spur, one that includes a SpurInbox. 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.
>
>> If Eliot had used proper branch names, this would not have happened. It's partly my fault because he asked me weeks ago if using multiple repos was the way to go and I did not foresee the problems this would cause.
>
> By contrast, the "Branches" approach wants to stuff everything into
> one big repository, and then employ some obscure, "implicit" filtering
> mechanism, known as "branches", to serve as the partition between the
> two projects. It's an additional concept whose implementation has
> extended its tendrils into many classes in the form of redundant case
> tests, and very much complicated the ability for tools to remain
> simple and Repository-independent.
>
> What do you think of Eliot's recently introduced preference,
> "Secondary Update URL"? Consider that it will be empty for 99% of
> Squeak users and, even for Eliot after he's long transitioned to Spur.
> When will this ever be used or ripped out in the future? Probably
> never to both questions. So I consider this as another example of
> low-value infrastructure (but at least harmless unlike the branches).
> I bet even Eliot would agree its hacky tacky, but it was considered a
> necessary evil at the time because we couldn't / didn't think hard
> enough for a way to avoid doing it. Separate repository anyone?
>
> Fewer parts and concepts is better than more, isn't 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. I have zero ego about this
> and I hope you do too.
>

Bert Freudenberg

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

In reply to this post by Chris Muller-3

On 18.06.2014, at 05:05, Chris Muller <[hidden email]> 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 -

smime.p7s (5K) Download Attachment

Chris Muller-3

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

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

Frank Shearar-3

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

On 18 June 2014 17:09, Chris Muller <[hidden email]> 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.

No, what I said what that if you have a hierarchy of branches more
than two levels deep, you have a problem.

So in the degenerate/base case you have one branch, right? "master" in
git, "default" in mercurial, and so on.

You can fork off master, giving you a branch master-a. The name's
arbitrary, and I'm using a naming scheme to highlight parent-child
relationships - what branches fork off what branches?

You can then fork off master-a, giving master-a-a. You can also create
master-a-a-a, master-a-a-a-a and so on. And this is where the wheels
come off. To get master-a-a-a into master, you should really merge
back to master-a-a, then to master-a, and finally to master. It takes
lots of time to merge all the way back to master. Every merge risks
conflicting edits. Deeply nested branches live much longer than ones
off master. That makes them diverge further from master, increasing
the risk of conflicting edits dramatically. And a conflict in merging
master-a will affect master-a-a, master-a-b, and all the other
branches off master-a.

That's not the same as having lots of branches. I _want_ lots of
branches: master-a, master-b, master-c, for as many features as are
currently in focus. I want these hordes of little branches
short-lived, because branching implies divergence, and nothing
prevents divergence better than not living long enough to diverge very
far.

frank

Eliot Miranda-2

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

In reply to this post by Chris Muller-3

On Wed, Jun 18, 2014 at 9:09 AM, Chris Muller <[hidden email]> 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

David T. Lewis

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

On Wed, Jun 18, 2014 at 07:22:19PM -0700, Eliot Miranda wrote:

> On Wed, Jun 18, 2014 at 9:09 AM, Chris Muller <[hidden email]> wrote:
>
> > 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.

I agree. This has been very important in the VMMaker repository. The MC history
shows the history of the branch for any given MCZ, and the branch tags give a
recognisable indication of which branch a given MCZ belongs to.

Indeed, I cannot think of a single case in which someone has accidentally stomped
on someone else's work in the VMMaker repository.

So I consider the branch-tags to be useful and very important.

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

No, the diff tools are telling you the truth. Sorry ;-)

I quite frequently browse the diffs of the VMMaker.oscog branch from an image
that is updated to the VMMaker branch. There are a lot of differences, but
the tools show them accurately. This is important and useful for comparing
and merging code from two branches.

I would say that branching works well and the tools are adequate.

Dave

tty

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

In reply to this post by Frank Shearar-3

Hi.

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

FWIW, the performance issues are not there today. I live in a fairly remote area, and internet is "interesting" at times, so that was probably the cause.

Also, if you think it will help things, feel free to nuke the repo and I can start the contributions from scratch. There are at least 2 false starts/approaches in that history that are not worth preserving for posterity--except for chuckles and examples of "how not to write software (: "

-tty.65 or so represents a cleaner start to the project.

cheers.

tty

Chris Muller-4

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

In reply to this post by Eliot Miranda-2

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

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.

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

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.

Nicolas Cellier

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

2014-06-19 17:38 GMT+02:00 Chris Muller <[hidden email]>:

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

Eliot Miranda-2

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

In reply to this post by Chris Muller-4

Hi Chris,

On Thu, Jun 19, 2014 at 8:38 AM, Chris Muller <[hidden email]> 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

Chris Muller-4

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

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

With simply a temporary ecosystem for spur, I don't see why we
couldn't simply throw it out. A cron or whatever uses your conversion
utility to regularly convert/copy new submissions from trunk to spur.
A clean separation-along-the-physical-seams rather than making
domain-soup like we're doing.

> Second, the non-branch scheme is at best confusing or at worst clashes in
> places like the package cache.

Yes, I acknowledge that loading stuff from the package-cache would
require a few extra clicks to identify what you wanted to load.. I
guess dedicated local file directory repositories (<-- plurality
important) would be the "normal" way to work offline?

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

Doesn't it? See below the ancestry of VMMaker, the transition from
the mainline to the "oscog" branch (54-55) followed by the next
descendant (55-56). Including the branched-name in the ancestry
actually makes sense to me; since that's the only way a FileBased
repository would be able to efficiently find the ancestral record..

"54-->55 transition into oscog branch."
Name: VMMaker.oscog-eem.55
Author: eem
Time: 26 April 2011, 11:47:29.937 am
UUID: 315353fc-7f75-4b5b-8a43-3a636cb1aa0b
Ancestors: VMMaker-oscog.54

"55-->56 first branched node is ancestor of the next descendant."
Name: VMMaker.oscog-eem.56
Author: eem
Time: 26 April 2011, 5:49:36.229 pm
UUID: fbf17bd2-ddbc-488f-b70d-3b9ba8906430
Ancestors: VMMaker.oscog-eem.55

I'm sure you can still remove the branch-name at some point, but the
record of it having gone through that branch will always be in the
ancestry for posterity.

It seems that I'm the only one who thinks MC branches are not worth
their costs. Our tools have bugs and limitations w.r.t. branch
support (like the selection-issue you mentioned in the meeting). That
means we can either put our energy into fixing them, or put energy
into transitioning to something simpler (or, of course, do nothing,
which means we live with the bugs). I, of course, prefer to simplify,
but since we are already this deep into them, I guess we'll just have
to manage it..

Tobias Pape

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

On 19.06.2014, at 21:21, Chris Muller <[hidden email]> wrote:

>>> 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.
>
> With simply a temporary ecosystem for spur, I don't see why we
> couldn't simply throw it out. A cron or whatever uses your conversion
> utility to regularly convert/copy new submissions from trunk to spur.
> A clean separation-along-the-physical-seams rather than making
> domain-soup like we're doing.
>
>> Second, the non-branch scheme is at best confusing or at worst clashes in
>> places like the package cache.
>
> Yes, I acknowledge that loading stuff from the package-cache would
> require a few extra clicks to identify what you wanted to load.. I
> guess dedicated local file directory repositories (<-- plurality
> important) would be the "normal" way to work offline?
>
>> 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.
>
> Doesn't it? See below the ancestry of VMMaker, the transition from
> the mainline to the "oscog" branch (54-55) followed by the next
> descendant (55-56). Including the branched-name in the ancestry
> actually makes sense to me; since that's the only way a FileBased
> repository would be able to efficiently find the ancestral record..
>
> "54-->55 transition into oscog branch."
> Name: VMMaker.oscog-eem.55
> Author: eem
> Time: 26 April 2011, 11:47:29.937 am
> UUID: 315353fc-7f75-4b5b-8a43-3a636cb1aa0b
> Ancestors: VMMaker-oscog.54
>
> "55-->56 first branched node is ancestor of the next descendant."
> Name: VMMaker.oscog-eem.56
> Author: eem
> Time: 26 April 2011, 5:49:36.229 pm
> UUID: fbf17bd2-ddbc-488f-b70d-3b9ba8906430
> Ancestors: VMMaker.oscog-eem.55
>
> I'm sure you can still remove the branch-name at some point, but the
> record of it having gone through that branch will always be in the
> ancestry for posterity.
>
> It seems that I'm the only one who thinks MC branches are not worth
> their costs. Our tools have bugs and limitations w.r.t. branch
> support (like the selection-issue you mentioned in the meeting). That
> means we can either put our energy into fixing them, or put energy
> into transitioning to something simpler (or, of course, do nothing,
> which means we live with the bugs). I, of course, prefer to simplify,
> but since we are already this deep into them, I guess we'll just have
> to manage it..

Chris, there is no way around having _some_ kind of branching mechanism
that supports multiple branches within the same repository. There is no
“simpler” there.
Without that we would fall years (decades?) behind other VCS, even
SVN or CVS, and _I_ am not willing to swallow that. Sorry, but I know
no way around this.

Best
-Tobias

signature.asc (1K) Download Attachment

Chris Muller-3

Re: Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

(Thanks, since I've already said enough publicly, I'm replying just privately).

>> It seems that I'm the only one who thinks MC branches are not worth
>> their costs. Our tools have bugs and limitations w.r.t. branch
>> support (like the selection-issue you mentioned in the meeting). That
>> means we can either put our energy into fixing them, or put energy
>> into transitioning to something simpler (or, of course, do nothing,
>> which means we live with the bugs). I, of course, prefer to simplify,
>> but since we are already this deep into them, I guess we'll just have
>> to manage it..
>
> Chris, there is no way around having _some_ kind of branching mechanism
> that supports multiple branches within the same repository. There is no

Why is "within same repository" a requirement?

> “simpler” there.
> Without that we would fall years (decades?) behind other VCS, even
> SVN or CVS, and _I_ am not willing to swallow that. Sorry, but I know
> no way around this.

Many projects using MC but not using MC branches, you're saying their
SCM is decades behind?

Probably not, because you know MC uses its ancestry for that..