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