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.tymc...@me.com
<mailto:yuriy.tymc...@me.com>> wrote:
On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goub...@cea.fr
<mailto:thierry.goub...@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.goub...@cea.fr
<mailto:thierry.goub...@cea.fr>> wrote:
Le 06/03/2014 10:08, Yuriy Tymchuk a écrit :
On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goub...@cea.fr
<mailto:thierry.goub...@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
