On 2/4/16 9:39 AM, Ben Coman wrote:
On Fri, Feb 5, 2016 at 1:08 AM, Dale Henrichs
<[email protected]> wrote:
On 2/3/16 10:53 PM, Thierry Goubier wrote:
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
<[email protected] <mailto:[email protected]>> 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,
My take on this is that we are not trying to "fix" Monticello.
The developers who prefer to use Monticello should continue to use
Monticello and the existing Monticello tools should continue to be
available. Any new formats should provide a migration path from Monticello
and any new tools like a `project list` tool should accommodate projects
based on both git and Monticello repositories.
This particular branch of the conversation has been aimed at trying to
resolve the tension that has been created by including Monticello metadata
in FileTree repositories and I think that "option 3": including past history
in the FileTree repository, but not updating the version history for each
git commit is a workable compromise --- there are always "issues down the
road" whether or not we see them and that shouldn't keep us from trying to
evolve:)
FileTree was invented (props to Otto Behrens) to smoothly integrate the use
of disk-based repositories into a Monticello development environment
dominated by Monticello tools.
Thierry your work building on the original FileTree has gone a long way
towards making git a viable development option for Pharo.
I think that you'd agree that the next step of evolution for "git-based"
development involves improved tool support and I would think that we should
turn our focus in that direction...
Dale
Pertinent is Joel's description of how Microsoft Excel's tipping point
[1] in competing against Lotus123 was when it became able to export to
Lotu123 format. Making it easy for people to move from git back to
Monticello lower the barrier for entry for people to use git.
[1] Scroll down to the second "tipping point"
http://www.joelonsoftware.com/articles/fog0000000052.html
That was the original rationale for including the Monticello metadata.
Unfortunately the implementation I chose interferes with the natural use
of git, so an alternate solution is needed. I think the technology is
present to be able to implement "option 3" in relatively short order and
we can look forward to this in a future release of FileTree[1].
But we also need to focus on improving the "git" support by the tools so
that developers can leverage some of the advantages that "git" brings to
the tble... developers need to be able to see version history at the
package, class, and method level; they need to be able perform the
"standard" git operations (commit, checkout, branch, diff, push, pull
...) without leaving the image; and they need to be able to do git
merges in the image ....
At least that's my opinion:)
Dale
[1] https://github.com/dalehenrich/filetree/issues/177
