Damien, Yes it was by design to just snapshot ... At the time, git was not necessarily familiar to most smalltalkers and I didn't want to require that git be installed or that a user understand how to use git, just to download and _use_ the code of a project that was hosted on github. A clone can be much larger than a simple snapshot and with the snapshot, I was able to create a git-cache directory that could be blown away at any time (much like the package-cache). Finally, if you wanted to save your changes you had to do these things outside the image. So _at the time_ the snapshot seemed to be a good compromise ... In my work flow, I tend to share most of my git repositories and I in this case I don't want N different git repositories for the same project on my disk... For that reason, the Metacello Preview has a feature for 'locking' a project. When you lock a project, you are telling Metacello that no matter what version or repository a project references always use the (in my case) local git repository... I pre-emptively lock the repositories that I am managing as local repositories and then I don't have to mess with reloading the version from my local repo ... If you have referenced a github repo and you do want to make a contribution to, then you should probably fork the project up on github and then clone a copy of your fork to the local disk and then "hook" the local clone into your image ... I have written some commands for tODE that automate this task ... and I'm willing to share:) Dale On Thu, Jul 10, 2014 at 9:28 AM, Damien Pollet <damien.pollet@gmail.com> 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 <thierry.goubier@cea.fr> 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 <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>> wrote:
Le 06/03/2014 11:09, Yuriy Tymchuk a écrit :
Sent from my iPhone
On 06 Mar 2014, at 10:28, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>> wrote:
Le 06/03/2014 10:08, Yuriy Tymchuk a écrit :
On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>> 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