Le 13/09/2013 17:04, b...@openinworld.com a écrit :
Goubier Thierry wrote:
Le 13/09/2013 04:25, Esteban A. Maringolo a écrit :
Is anybody using FileTree repositories?
Which repositories? Dale's github?
If so, I'd like to know the pros and cons of using it.
More complex to use than Smalltalkhub/Squeaksource because it is not
yet integrated in the default image. Some features may not work, but
average MC work under Pharo2.0 works fine with all features of
Filetree (including gitfiletree).
Easier to use than Smalltalkhub/Squeaksource for authentification.
I want to use to version everything with git, but I don't know how it
keeps git (it is, FileTree files) in sync with MC versions.
A filetree repository appears as a MC repository in the same way as
another type of MC repository.
Filetree will require that you do all your version management in the
git repo by hand (i.e. save a version of your package in a filetree
repo, then switch to a console to commit it. If you forget to commit
and save a new version of a package on the filetree repo, you
overwrite the previous version and git will not record it. Filetree by
itself will only show you the state of the HEAD of your git repository).
If you use gitfiletree (it sits over Filetree), then git commit will
be done for you when saving your package, and the repository browser
will show you all the history of the repository, exactly as if it was
a Smalltalkhub or Squeaksource repository. What will remain to do on
the command line are the git push and whatever management you do on
the repository (merging, branching, even if you can also merge via MC
instead). In short, gitfiletree calls git for you and parse the
results :)
I'm still wondering about adding more git commands inside the MC GUI
to do more from inside Pharo (like automagically pushing), but I don't
want to enforce a specific way of organising the git repository... and
I'm just trying to get gitfiletree to pass its tests in the pharo3.0
branch of Filetree at the moment.
Does this answer your questions?
Thierry
> but I don't want to enforce a specific way of organising the git
repository
I see this extreme altruism :) around the community, and while it is
very admirable, I think sometimes its misplaced :). The flip side is
that some people (like me) aren't really familiar with git don't know
how we might want git organised, or even what the options are.
Unfortunately this stalls my motivation to try it out (sorry, weak, I
know - but I admit it, and I think its common (or do I just think that
to make myself feel better)). Having a concrete implementation of any
additional functionality that might make git more transparent "out of
the box" would be beneficial for its uptake. As well, without a
concrete example, others who might want to implement something like that
have to start more from scratch, whereas your concrete example might be
90% of what someone wants and then its only 10% that they need to
customize. The reality of human nature is that its easier to criticize
to pick out what you don't like, than to create something new. However
the hidden benefit of this criticism is that it engages people in
discussion and then you hook them into helping develop what they need.
So anyway, my short response is, if "you" would benefit from that added
functionality then "just do it". :)
cheers -ben
P.S. I admire what I read about progress with Filtetree and GitFileTree
towards using git. For some segments outside the Pharo community that
we want to draw in, this is going to be an important consideration.
Hi Ben,
I'm sorry that this doesn't convince you to use git with Pharo :)
So far, I very happy with the functionality gitfiletree has; for a
common user like me it has been working very nicely for quite some time
now :):) It has the features I need: allow the introduction of pharo
development in any pre-existing / mixed language repository; allow me to
build in 5 sec a new repo for a package; integrate with github; better
long history exploration than anything else under Pharo.
At the same time, it was a bit of a mock-up, this gitfiletree: just
adding some automation to a filetree over git repository, and also add
some motivation for someone else to see what can be done and how, so as
to eventually reimplement it as a FileSystem / or as a libcgit instead
of calling git log and git archive :)
It's now a bit of a bench for some future directions of FileTree, such
as removing the metadata which is provoking conflicts when merging under
git, or as a new replacement of changesets (but EPICEA is going in
another interesting direction, so I'm not trying anything there).
And don't worry for my altruism not adding functionalities :) I'm the
guy who wrote a complete alternative IDE for pharo 2.0, just because I
prefer it to Nautilus :O
Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
