On 11/8/15 2:04 PM, Thierry Goubier wrote:
Le 08/11/2015 17:41, Dale Henrichs a écrit :
On 11/7/15 10:00 AM, Thierry Goubier wrote:
Oh yes,
I can announce that from now on, the development version of GitFileTree for Pharo 5 handles FileTree repositories without most of the metadata (precisely version and methodProperties).
This makes the format a lot more DVCS friendly (Git, Fossil, Hg, SVN, all...) by cutting the noise on diffs and conflicts on merge and cherry picking.
Note: it only apply to brand new repositories; nothing is changed for pre-existing ones.
Note2: reading those Metadata-less repositories with FileTree does give you packages without metadata: no version history, no author, no author nor timestamp on methods.
Note3: it is possible to hack a repo from metadata to non-metadata mode, but I won't explain it.
Enjoy and tell me how it works for you. I'm especially interested by heavy branchers/mergers reports :)
Thierry
Thierry,
You want to double check that Metacello works correctly with these metadata-less packages ... if you are continuing to increment the "package version" there shouldn't be a problem, but when I did a similar experiment a year or so ago, I found that I had to teach Metacello to ignore the "package version" and load the package anyway ... the normal procedure for Monticello packages and Metacello is not load a package if the "package version" is less than or equal to the package already loaded .... I did make an extension to Metacello to make this work .... I can hunt it up if needed and make it part of the standard release (I may have kept it as part of tODE) ...
Hi Dale,
GitFileTree without metadata on disk does not mean no metadata for Monticello/Metacello to work with; as long as you reach the git log info, then it will work exactly as usual (incrementing version numbers, etc...), with the usual caveats (i.e., if you limit depth when cloning with git, version numbers do change).
However, when accessing via FileTree (for example github:// urls), then, yes, version numbers become 1.
It will only matter when updating an already loaded project via a github:// or bitbucket:// url. And there, simply allowing Metacello to load if repository version is >= to existing version should take care of it. This is the sticky wicket ... what I did to "solve the problem" was to define a Cypress url (I think) that would arrange for the proper loading to take place (ignore monticello meta data and load unconditionally) .... this sounds bad, but Monticello is smart enough to only load the changed definitions, so loading the same package over and over will not load anything ... you do get the overhead of ccreating definitions from disk ... but that might not be as big a deal these days ...
I have an idea of possible solutions. We'll see how it goes and solve that when we'll have a serious push around git ;)
Agreed ... I just wanted to point out this potentially surprising tidbit:) Dale