2016-02-04 10:26 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com>:

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?

Sure. Consider it's somehow like a git squash...

��

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)

But that's the same with over vcs, repositories disappear and die (google code etc...).

Knowing that you can take usual defensive decisions (replicate what you depend on and not trust too much).
��

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

Loosing a .mcz on which you branched is a bit more than unfortunate, it's a lack of understanding of the tool...

I say give git squash and rebase to unexperimented/uninformed people and that will be far worse.

��

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.

Do you mean that git succeeded in merging text because different lines were changed in different branches?

I agree that it can solve some basic refactoring (renaming...)

But couldn't it lead to syntactically incorrect code? Traditional Smalltalk IDE are not well equipped for handling this...

The biggest grief I have with MC is more about package delimitation, when code is moved from 1 package to another.

For example, this effectively prevent merging very distant branches like Squeak and Pharo

(but we do not want to merge, just cherry pick in fact).

��

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.

As long as it's as efficient, and well integrated in IDE, but again, it's against the small steps approach...

For me small steps would be to replace mcz name indexing by UUID indexing and just keep name as a fa��ade.

I'm quite sure most work is at server side. How difficult would it really be?

No one will consider this maybe, because it's against the stream ;)

��

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.

But Cuis vcs come from dinosaure era (change sets) so anything else is already a progress.

Doing that in Squeak would feel like a loss of tool/functionality/integration.

Why didn't Pharo took the same path?

Thierry

2016-02-04 7:53 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com
<mailto:thierry.goubier@gmail.com>>:

�� 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
�� <thierry.goubier@gmail.com
�� <mailto:thierry.goubier@gmail.com>
�� <mailto:thierry.goubier@gmail.com

�� <mailto:thierry.goubier@gmail.com>>> 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