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, [email protected] <[email protected]> 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 <[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
--
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
