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? ----- Cheers, Sean -- View this message in context: http://forum.world.st/GitFileTree-Version-Numbering-tp4810543.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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? ----- Cheers, Sean -- View this message in context: http://forum.world.st/GitFileTree-Version-Numbering-tp4810543p4810614.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
2015-03-09 11:39 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
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?
No problem, just make a correct clone with the full history of your MC repository and you'll get the right version number :) 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 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. Thierry
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/
participants (3)
-
Martin Bähr -
Sean P. DeNigris -
Thierry Goubier