Le 04/02/2016 14:32, Nicolas Cellier a écrit :
2016-02-04 10:26 GMT+01:00 Thierry Goubier <thierry.goub...@gmail.com
<mailto:thierry.goub...@gmail.com>>:
Le 04/02/2016 10:04, Nicolas Cellier a écrit :
[... cut ]
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...
I consider history rewriting a very bad idea...
But, if we are at that, I just consider that the removed versions do not
exist anymore, and are not visible (should not be visible) in the
history, and that you have perfectly predictable correct behavior, not
can't do this because package version X is missing.
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).
I mean that VCS recreate a working history and log when you are in such
a situation. MC just let you believe you have all and fail when you
attain the holes.
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...
Not true. MC let you believe it will cope and it doesn't, which is not
exactly the same.
I say give git squash and rebase to unexperimented/uninformed people and
that will be far worse.
Agreed.
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?
No, in fact it was a clean merge because the changes in the branch were
on methods untouched in the main... git recreated a proper history and
could merge, whereas MC with the mcz history generated conflicts without
any reason.
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...
Yes, this is partly why we're looking at more integration (merge tool)
and we may have to do more (a smalltalk syntax checker before commit
could be nice; CI does wonders on that).
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).
Ok. Merge with multiple packages, right?
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'd agree with that, as long as you don't ask too much of
compatibilities with some of MC features (:)).
I'm quite sure most work is at server side. How difficult would it
really be?
Why server side? I don't think it is.
No one will consider this maybe, because it's against the stream ;)
No, in fact we're on it. Git integration is showing us where MC is weak,
and we're trying to fit it with MC.
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.
I agree.
Why didn't Pharo took the same path?
Than Cuis?
Thierry
Thierry
2016-02-04 7:53 GMT+01:00 Thierry Goubier
<thierry.goub...@gmail.com <mailto:thierry.goub...@gmail.com>
<mailto:thierry.goub...@gmail.com
<mailto:thierry.goub...@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.goub...@gmail.com
<mailto:thierry.goub...@gmail.com>
<mailto:thierry.goub...@gmail.com
<mailto:thierry.goub...@gmail.com>>
<mailto:thierry.goub...@gmail.com
<mailto:thierry.goub...@gmail.com>
<mailto:thierry.goub...@gmail.com
<mailto:thierry.goub...@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
