Contributing to Pharo

Le 04/02/2016 10:04, Nicolas Cellier a écrit :

I don't understand broken history either.
Yes there can be .mcz name clashes but UUID history is stored together
in metadata no?

Yes.

If some tool only trust .mcz name without checking UUID, consider it's a
bug, and let's correct it (there is some in Monticello Configuration Map)

Gofer. In fact, most of Monticello never checks the UUID, only dependencies do, but this looks like a deprecated feature given how often it is used.

Or is it the fact that some .mcz could be missing?
Consider this is a feature, MC tools are robust to missing .mcz (it's
just that you'll have to redo the merge if you lost a common ancestor).

What? You really consider that a feature?

Or is it the fact that some repository might contain only a slice of
history?
This is another feature... You can view all the versions in a collection
of repositories without needing to replicate.

Understandable in theory. Unworkable over time and change (repositories disappear and die, and this stops working)

You can replicate if you want but it's not mandatory and completely
orthogonal.
So yes, this information - the list or repositories you want to consider
- has to be stored separetely and this can sound quite unconventional.
But IMO, it's an important feature: it gives much resilience for a very
low investment.
And that also mean that you can hardly break things (have unconsistent
history).

Maybe when you say broken, you mean not 100% git compatible?

No, what I say is true mcz inconsistent history (missing versions making merges very unreliable, basically).

I describe a while ago a case where, thanks to mcz features, I couldn't merge a small change done to Roassal without generating a ton of conflicts. I moved the three needed mcz(s) to git (the change ancestor, the change, and the current head), did git merge and had no conflicts.

If you consider those features, then I disagree.

I'd really like to improve MC and get a better integration. Considering those as features just make me think that Eliot may well be right in believing we'll end up throwing away MC completely.

Coping with MC idiosyncrasies is hard as it is, and at least a complete replacement is being considered for Pharo. In the meantime, Cuis has completely given up managing packages in Smalltalk: all is done in git, externally.

Thierry

2016-02-04 7:53 GMT+01:00 Thierry Goubier <[hidden email]
<mailto:[hidden email]>>:

    Le 03/02/2016 23:58, Dale Henrichs a écrit :



        On 02/03/2016 02:34 PM, Thierry Goubier wrote:

            Le 03/02/2016 22:51, Eliot Miranda a écrit :



                On Wed, Feb 3, 2016 at 12:54 AM, Thierry Goubier
                <[hidden email]
                <mailto:[hidden email]>
                <mailto:[hidden email]

                <mailto:[hidden email]>>> wrote:

                     Hi Eliot,

                     Le 02/02/2016 21:54, Eliot Miranda a écrit :
                       ....


                         No it's /not/ the end of the story.  The
                essential part of the
                         story is
                         how Monticello remains compatible and
                interoperable between
                         dialects.  I
                         haven't seen you account for how you maintain that
                         compatibility.  As
                         far as I can tell, you propose replacing the
                Monticello metadata
                         with
                         that from git.  How do I, as a Squeak user with
                Monticello, ever
                         get to
                         look at your package again?  As I understand
                it, moving the
                metadata
                         from Monticello commit time to git means that
                the metadata is
                in a
                         format that git determines, not Monticello.


                     Yes. See below why.

                         So I don't understand how on the one hand you
                can say "The
                         Monticello
                         metadata in a git repository is redundant and
                leads to
                unnecessary
                         commit conflicts -- end of story ....", which
                implies you
                want to
                         eliminate the Monticello metadata, and on the
                other hand you say
                         you're
                         keeping the Monticello metadata.  I'm
                hopelessly confused.  How
                         does the
                         Monticello metadata get reconstituted if it's
                been thrown away?

                         What happens to the metadata in the following
                workflow?

                         load package P from Monticello repository R
                into an image
                         change P, commit via git to local git repository G
                         load P from G into an image
                         store P to R via Monticello


                     It's not a scenario I've specifically worked on,
                but all the tech is
                     implemented / implementable to do that perfectly.

                     The only thing that is problematic there is that
                the only safe
                     history is the one generated from git... there are
                so many MC
                     packages with broken history that, on mcz packages,
                you have to
                     admit that it's not safe to base things on their
                history.


                I'm sorry but I don't accept that.  In the Squeak trunk
                we have history
                in our mczs that is correct.  Certainly in VMMaker.oscog
                I have history
                that goes back a long time.  If bugs have broken history
                then efforts
                should be made to repair that history.  But you can't
                just write off
                Monticello history like that.


            I don't. You presuppose.

            I write tools that work with Monticello repositories, not
            just yours.
            I have to do with what is given to me. On a general level,
            as a mcz
            user, I'll just have to consider that you are as susceptible
            to be
            trusted as with any other mcz producer. This means not much...


        ... And this is the reason why I am inclined to favor option 3,
        which
        records the package version history as it existed at the point
        it was
        copied into a git repo. When copied back out from the git universe,
        create a version history that starts with the original version
        history
        and generates a history of the package in git ....


    Which is not very difficult to do given how GitFileTree is
    implemented. And I agree this may well be the way to go. But ...

        Correct or not, the Monticello version history should be
        preserved ....


    I wonder about that. The property of the Monticello version history
    is that it has value when you can access the versions listed in it.
    If you mix repositories like that, unless you maintain a link to the
    previous mcz repository, pre-git versions can't be accessed. So,
    most of the time, what we do with a project moved under git is to
    clone the previous repository, not take just the current head.

    (you'll notice, by the way, that vcs usually work that way when
    moving from, say, CVS to git - you move the entire repository, not
    just the latest version).

    In short, the question would really be:
    1- should we invest into making that integration of past history a
    selling point (but I foresee issues down the road; I've only
    described one so far, and I have seen others)
    or
    2- into making a better "clone" of a package history, timestamps and
    everything when moving a complete repository to git?

    Honestly, I'd consider 1- to be the easiest to implement. 2- there
    is already some code floating around.

    Thierry

> On 04 Feb 2016, at 10:26 , Thierry Goubier <[hidden email]> wrote:
>
> Le 04/02/2016 10:04, Nicolas Cellier a écrit :
>> I don't understand broken history either.
>> Yes there can be .mcz name clashes but UUID history is stored together
>> in metadata no?
>
> Yes.
>
>> If some tool only trust .mcz name without checking UUID, consider it's a
>> bug, and let's correct it (there is some in Monticello Configuration Map)
>
> Gofer. In fact, most of Monticello never checks the UUID, only dependencies do, but this looks like a deprecated feature given how often it is used.
>
>> Or is it the fact that some .mcz could be missing?
>> Consider this is a feature, MC tools are robust to missing .mcz (it's
>> just that you'll have to redo the merge if you lost a common ancestor).
>
> What? You really consider that a feature?
>
>> Or is it the fact that some repository might contain only a slice of
>> history?
>> This is another feature... You can view all the versions in a collection
>> of repositories without needing to replicate.
>
> Understandable in theory. Unworkable over time and change (repositories disappear and die, and this stops working)
>
>> You can replicate if you want but it's not mandatory and completely
>> orthogonal.
>> So yes, this information - the list or repositories you want to consider
>> - has to be stored separetely and this can sound quite unconventional.
>> But IMO, it's an important feature: it gives much resilience for a very
>> low investment.
>> And that also mean that you can hardly break things (have unconsistent
>> history).
>
>> Maybe when you say broken, you mean not 100% git compatible?
>
> No, what I say is true mcz inconsistent history (missing versions making merges very unreliable, basically).
>
> I describe a while ago a case where, thanks to mcz features, I couldn't merge a small change done to Roassal without generating a ton of conflicts. I moved the three needed mcz(s) to git (the change ancestor, the change, and the current head), did git merge and had no conflicts.
>
> If you consider those features, then I disagree.

Also, the ancestry of all packages in Pharo Core was truncated a few years back, which also screwed up merging*.
I don't think anyone looked into why it happened.

Cheers,
Henry

*http://forum.world.st/FogBugz-Case-Issue-12776-Tools-Cancelling-quot-Previous-Contents-quot-in-a-Workspace-clears-the-currs-td4753381.html