GitFileTree Version Numbering

When copying MyPackage-Author-VersionNumber.mcz to an empty GitFileTree repository, VersionNumber is not considered, and it appears in the version browser as MyPackage-Author-1, which seems confusing. Could it keep the same VersionNumber?

Le 09/03/2015 04:20, Sean P. DeNigris a écrit :
> When copying MyPackage-Author-VersionNumber.mcz to an empty GitFileTree
> repository, VersionNumber is not considered, and it appears in the version
> browser as MyPackage-Author-1, which seems confusing. Could it keep the same
> VersionNumber?

No ;)

It takes ages to scan the version metadata contained in the git repository.

This version metadata is wrong in some existing repositories (and
crashes the reader).

So GitFileTree rebuilts the version (number included) from scratch.

Thierry

Excerpts from Thierry Goubier's message of 2015-03-09 07:06:41 +0100:
> Le 09/03/2015 04:20, Sean P. DeNigris a écrit :
> > When copying MyPackage-Author-VersionNumber.mcz to an empty GitFileTree
> > repository, VersionNumber is not considered, and it appears in the version
> > browser as MyPackage-Author-1, which seems confusing. Could it keep the same
> > VersionNumber?
>
> No ;)
>
> It takes ages to scan the version metadata contained in the git repository.

why is that?
it works when being read from an mcz file. how would reading it from git be any different?

> This version metadata is wrong in some existing repositories (and
> crashes the reader).

wrong in monticello repos?

> So GitFileTree rebuilts the version (number included) from scratch.

what about just extracting the version from the very first commit?
and then increment the number for all following commits?

greetings, martin.

--
eKita                   -   the online platform for your entire academic life
--
chief engineer                                                       eKita.co
pike programmer      pike.lysator.liu.se    caudium.net     societyserver.org
secretary                                                      beijinglug.org
mentor                                                           fossasia.org
foresight developer  foresightlinux.org                            realss.com
unix sysadmin
Martin Bähr          working in china        http://societyserver.org/mbaehr/

Martin Bähr wrote

> It takes ages to scan the version metadata contained in the git repository.
why is that?

Also, this is a copy operation, so we already have the version number from the mcz! Why can't we just use that?

Excerpts from Thierry Goubier's message of 2015-03-09 13:13:23 +0100:
> There is technical limitations in adding that information (or using it). I
> did use it a long time ago at the beginning of gitfiletree, but it was
> prohibitively slow, even on small git repositories.

i find this puzzling. when monticello creates the archive, is it not the
version somewhere accessible in the object? it has to come from somewhere,
doesn't it?

filetree (i believe) writes the version and history into
PackageName.package/monticello.meta/version

i assume you tried reading that? is that what is slow?
was the problem to check out the version in order to get the file, or was there
a problem reading it?

> I would have been pleased by a Package-Author.Commit.mcz approach however,
> but the numbering scheme in MC is so hopelessly broken and unreliable
> anyway that it's not worth the hassle. The only thing correct in MC is the
> UUID, but, except in very specific cases, it isn't used because it's too
> costly to check it.

because the mcz needs to be unpacked to get it, i guess?

greetings, martin.

--
eKita                   -   the online platform for your entire academic life
--
chief engineer                                                       eKita.co
pike programmer      pike.lysator.liu.se    caudium.net     societyserver.org
secretary                                                      beijinglug.org
mentor                                                           fossasia.org
foresight developer  foresightlinux.org                            realss.com
unix sysadmin
Martin Bähr          working in china        http://societyserver.org/mbaehr/