Metacello-github + filetree-git async
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. Any clue what can be the problem? Uko
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?
Any clue what can be the problem?
A few possibilities: a) A missing pull or push on the gitfiletree repository (one more commit on the central repository not seen locally, or the reverse) b) Incoherent versions between the 'version' metadata of the package and the git-extracted version metadata; but this would not show changes visible (unless combined with a), where it's possible for the older version to have a bigger version number. Ways to test: - When opening the repository on the local machine, is the Push button greyed out or not. If not, there are local changes not visible to the global repository. - Check that the top most commit visible in your local gitfiletree repository (git log on the command line) is the same as the one listed on github. 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
On 06 Mar 2014, at 09:48, Goubier Thierry <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".
Any clue what can be the problem?
A few possibilities: a) A missing pull or push on the gitfiletree repository (one more commit on the central repository not seen locally, or the reverse) b) Incoherent versions between the 'version' metadata of the package and the git-extracted version metadata; but this would not show changes visible (unless combined with a), where it's possible for the older version to have a bigger version number.
Ways to test: - When opening the repository on the local machine, is the Push button greyed out or not. If not, there are local changes not visible to the global repository. - Check that the top most commit visible in your local gitfiletree repository (git log on the command line) is the same as the one listed on github.
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
Le 06/03/2014 10:08, Yuriy Tymchuk a écrit :
On 06 Mar 2014, at 09:48, Goubier Thierry <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? Remember that github: and filetree: do not read versions in the same way as gitfiletree:; they are usually in sync, but may be desynchronized. 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
Sent from my iPhone
On 06 Mar 2014, at 10:28, Goubier Thierry <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> 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.
Remember that github: and filetree: do not read versions in the same way as gitfiletree:; they are usually in sync, but may be desynchronized.
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
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> wrote:
Le 06/03/2014 10:08, Yuriy Tymchuk a écrit :
On 06 Mar 2014, at 09:48, Goubier Thierry <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? 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
On 06 Mar 2014, at 11:17, Goubier Thierry <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> wrote:
Le 06/03/2014 10:08, Yuriy Tymchuk a écrit :
On 06 Mar 2014, at 09:48, Goubier Thierry <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.
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
On 06 Mar 2014, at 11:35, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 06 Mar 2014, at 11:17, Goubier Thierry <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> wrote:
Le 06/03/2014 10:08, Yuriy Tymchuk a écrit :
On 06 Mar 2014, at 09:48, Goubier Thierry <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
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
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
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 <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
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 - 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?) This promises to coalesce into a nice workflow, though. Can't wait :D On 10 July 2014 18:47, phil@highoctane.be <phil@highoctane.be> 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 <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
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Damien On Thu, Jul 10, 2014 at 9:59 AM, Damien Pollet <damien.pollet@gmail.com> wrote:
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)
Thierry's MergeDriver has made the monticello meta data conflicts a non-issue ... since using his merge driver they've gone away as far as I am concerned ... I don't think the meta data can go away until a firm break with mcz files has been made and this cannot really happen until the image has full tool support for working with pure git repos and even then there will be a transition period ... - gitfiletree is a pain because it insists on using a file browser
that shows all dotfiles and starts in the stupidest of places - 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?)
This promises to coalesce into a nice workflow, though. Can't wait :D
I cannot comment on the other things, but for GemStone I am building git support into tODE and have created a `project list` that I think supports git work flow in the "right way" (I am doing a pre-alpha release shortly, I will find out:) ... but the point of this is that I think you almost have to build a new tool suite for managing projects and git repos together and that just takes time ... the old package-base tools are not quite at right level, since with git it is possible to look at method history, class history, package history and project history and when you do a commit, you should be committing all of the packages in the project at the same time (or at least have the option of doing so)... Dale
________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Damien Pollet [damien.pollet@gmail.com] 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-td4740... 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, phil@highoctane.be <phil@highoctane.be> 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 <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
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Le 10/07/2014 18:59, Damien Pollet a écrit :
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
Damien, I looked and this stupidest of places of yours is YOUR settings path for your package-cache. Used also by filetree. And all other file-based repositories in Monticello. Regards, Thierry
- 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?)
This promises to coalesce into a nice workflow, though. Can't wait :D
On 10 July 2014 18:47, phil@highoctane.be <phil@highoctane.be> 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 <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
-- 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, 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
participants (6)
-
Dale Henrichs -
Damien Pollet -
GOUBIER Thierry -
Goubier Thierry
-
phil＠highoctane.be -
Yuriy Tymchuk