________________________________________ De : Pharo-dev [[email protected]] de la part de Damien Pollet [[email protected]] Envoyé : jeudi 10 juillet 2014 18:59 À : Pharo Development List Objet : Re: [Pharo-dev] Metacello-github + filetree-git async
as far as I am concerned (I'm certainly not up-to-date on recent enhancements)… - filetree is a pain because of the double-commit workflow (MC with dummy message to serialize, then git) - gitfiletree is a pain because it insists on using a file browser that shows all dotfiles and starts in the stupidest of places Starting in one of the default places linked to the image. Yes, this is annoying... I'll look into it. - github is just a snapshot (no updates, no contributions) - there is a mysterious new "remote git repo" that either uses gitfiletree or the new libgit2 bindings, but I'm not sure what all the parameters are exactly (name of what? subdirectory of where?) GitFileTree for the time being: http://forum.world.st/ANN-GitFileTree-with-no-git-command-line-at-all-td4740317.html This promises to coalesce into a nice workflow, though. Can't wait :D It works as of now :) I'm trying to document some of it in the GitAndPharo chapter of Pharo for the enterprise. Thierry On 10 July 2014 18:47, [email protected] <[email protected]> wrote: > I am interested to know too. > > ATM I do a clone and use filetree:// > > Phil > > > > On Thu, Jul 10, 2014 at 6:28 PM, Damien Pollet <[email protected]> > wrote: >> >> Sorry to hijack this discussion… is it by design that the github: >> scheme takes a snapshot instead of a git clone? >> >> github: is convenient for the metacello syntax, but since it just >> takes a snapshot of a commit, there is no immediate way of pushing >> changes back. Converting what's on disk to a proper git clone is also >> not practical since the path of the snapshot under github-cache is >> specific to the particular commit. >> >> On 6 March 2014 13:42, Goubier Thierry <[email protected]> wrote: >> > Ok, I see now. >> > >> > I don't think this can be avoided; it's inherent in the way both github: >> > and >> > gitfiletree: understand repositories. The explanation will go a bit into >> > git >> > and gitfiletree design and FileTree; in the mean time, you may either >> > change >> > a bit the config to clean that (force a load of the last version from >> > gitfiletree, since they are effectively the same) or don't bother, >> > gitfiletree: when saving a new package version will clear that (sort >> > of). >> > >> > The explanation is a bit long. >> > >> > version metadata for FileTree (the format used to write packages for git >> > and >> > others version control systems) is stored in a file under >> > PackageName.package/monticello.meta/versions. >> > >> > This file is often a problem, at least under git: it's a magnet for git >> > merge conflicts. It is also slow to parse[1], especially if you want to >> > know >> > all the versions of the package stored by the git repository (as >> > gitfiletree >> > does), and sometimes is corrupted (git conflicts). >> > >> > So, in the design of gitfiletree:, I decided that I would not read this >> > file, but, instead, recreate its contents from the git log history[2]. >> > This >> > is what you see when you open a gitfiletree: repository. And >> > particularly, >> > versions UUIDs are generated from the git commit ID[3]. >> > >> > Now, when saving a package in a gitfiletree: repository, the versions >> > file >> > will be written, with an UUID generated for it... except that, on >> > rereading, >> > gitfiletree will generate another UUID from the git commitID (which is >> > known, of course, after committing the versions file :() >> > >> > For example, in gitfiletree:, >> > Renraku-Uko.4 has UUID: 93fec7ab-e167-5da5-9b2e-5d717d2c7545 >> > Whereas the file Renraku.package/monticello.meta/versions has >> > Renraku-YuriyTymchuk.4 with id >> > '60141668-a324-4c9d-8938-db82ed2e57de' >> > >> > Older versions are regenerated from the git data, and this is why, in >> > that >> > file, you see >> > Renraku-Uko.3 (and not Renraku-YuriyTymchuk.3) >> > >> > [1] Yes, and I tried long and hard to accelerate reading and parsing 200 >> > times the versions file for a moderatly complex project, including the >> > fact >> > that it's easy to find a corrupted versions file in a git repo. >> > Generating >> > ended up a lot cleaner, as well as garanteeing than the history would be >> > browsable. >> > >> > [2] And filtering the git history to keep only the commits significant >> > for >> > the package, and nothing else. >> > >> > [3] Constant mapping: a given git commitID will allways generate the >> > same >> > UUID. >> > >> > Le 06/03/2014 11:41, Yuriy Tymchuk a écrit : >> >> >> >> >> >> On 06 Mar 2014, at 11:35, Yuriy Tymchuk <[email protected] >> >> <mailto:[email protected]>> wrote: >> >> >> >>> >> >>> On 06 Mar 2014, at 11:17, Goubier Thierry <[email protected] >> >>> <mailto:[email protected]>> wrote: >> >>> >> >>>> >> >>>> >> >>>> Le 06/03/2014 11:09, Yuriy Tymchuk a écrit : >> >>>>> >> >>>>> >> >>>>> >> >>>>> Sent from my iPhone >> >>>>> >> >>>>>> On 06 Mar 2014, at 10:28, Goubier Thierry <[email protected] >> >>>>>> <mailto:[email protected]>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a écrit : >> >>>>>>> >> >>>>>>> >> >>>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <[email protected] >> >>>>>>> <mailto:[email protected]>> wrote: >> >>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Le 06/03/2014 09:32, Yuriy Tymchuk a écrit : >> >>>>>>>>> >> >>>>>>>>> Hi guys. >> >>>>>>>>> >> >>>>>>>>> My workflow is like this: >> >>>>>>>>> >> >>>>>>>>> I load a configuration on CI with github:// magic in metacello >> >>>>>>>>> conf. >> >>>>>>>>> Then on local machine I add a local gitfiletree repo to the >> >>>>>>>>> project packages. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> The thing is that the last version if loaded, but gitfiletree >> >>>>>>>>> repo is showing that second last is loaded. And yes, diffs with >> >>>>>>>>> last one (not loaded by gitfiletree opinion) show no changes and >> >>>>>>>>> diffs with second last (current one by gitfiletree opinion) show >> >>>>>>>>> changes that were mede in last version. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Say version .5 on CI, and gitfiletree is showing you only .1, .2, >> >>>>>>>> .3, and .4 , like that? >> >>>>>>> >> >>>>>>> >> >>>>>>> I also see the .5 version, but it’s bold i.e. “not loaded". >> >>>>>> >> >>>>>> >> >>>>>> Are changes shown when you click on the .5 version in gitfiletree? >> >>>>>> on the .4 version in gitfiletree as well? >> >>>>> >> >>>>> >> >>>>> Version 5 does not have changes with working copy. While version 4 >> >>>>> has. So from my point of view it seams like version 5 is loaded but >> >>>>> gitfiletree thinks that only version 4 is loaded. >> >>>> >> >>>> >> >>>> Understood. Is it a problem if I have a look at the image or at the >> >>>> git repository? >> >>> >> >>> >> >>> When I look in the monticello browser in the image. >> >> >> >> >> >> And with applies to the both packages I have in that repo >> >> >> >>> >> >>>> >> >>>> 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 >> >> >> >> >> > >> > -- >> > 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 >> > >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
