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
