ottobehrens
commented
8 years ago As described in this post, it seems that a reasonable compromise for dealing with Monticello metadata, is that the *.package/monticello.meta/version file be a copy of the Monticello version history when a package is copied into a FileTree repo. Newly created packages (not via copy) would contain an empty version file. The Monticello metadata would not be updated on every commit .... When a package is copied then it becomes necessary to fabricate a revision history to bridge the gap between the original Monticello version history and the present commit - this fabricated version history may account for every git commit since the version file was last changed, or simply a new commit referencing the current SHA ...
this solution could involve adding some new MCAncestry classes that would record the url and SHAof git commits ...making it possible to merge two Monticello packages with a common ancestor somewhere in the git history ... or we could treat the git world as a series of lost mcz files .... If we do support merges involving a specific SHA in github, then new MC classes and support would be required which has impacts on older versions of the images trying to do the merge or even read the packages ... adding fields in the commit comment using JSON or STON containing the fields of interest would probably solve the backward compat problem while allowing newer tools to support such a merge ...
Finally we need to resolve the handling of the methodProperties files .. those files are there only for the Monticello meta data and we could drop these files altogether if we fabricated method definitions that picked this information from the latest commit that involved the file ... for performance reasons, I would be inclined to not include this information unless a package was being prepared for export via copy to repository ...
I think we should have a bit of free form discussion (i.e., what code can be leveraged from @ThierryGoubier and GitFileTree? and what does @ottobehrens do in his current FileTree implementation?)
We currently .gitignore the version files and generate them just before we load into Pharo / GS. We use the SHA1 of the package directory to generate the UUID with and arbitary commit message, date and time. Ancestors and stepChildren are empty. We derive the version number from the SHA1, (between 1 and 10000) which ensures that the version number changes.
One of the issues I'm curious about is how to get past the Monticello/gofer/Metacello? feature that skips loading a version of a Monticello package with a lesser version number ... I know that I have code that addresses this for Metacello (in a separate class for Cypress packages), but we might need to jigger the loader or whatever to make this work but I think that both of you (@ThierryGoubier and @ottobehrens) have dealt with this (and I've forgotten the details)?
This feature is a surprise! I did not know that a lesser version number was skipped! So we reload all the packages after an initial load. To make really sure that it is all loaded. We also found that unresolved dependencies are not properly resolved. Yes, our package structure sucks and we have circular dependencies.
What would be nice is that if I give Gofer a list of packages to load, that it would load them, without trying to think if the version number is more recent or not.
I'm not in a hurry to implement this, but I think that it should bump up in priority because it will eliminate the need for the GitMergeTool and make life for the folks working purely in git much simpler, while making it possible for folks choosing not to use git to work with and contribute to projects that have been moved to git/github ...
I agree, this is a basic problem to resolve. We use the git command line to merge.
We had a better solution for generating the version files. We counted the number of commits for a package directory in the git repository, which ensured that the version number increased. We also took the comment from the most recent commit of that package, with the date and time. The problem was that this is slow. Searching through the git repo for ancestors of each of our packages took a good 20-30 seconds, which we needed every time we loaded something.
ThierryGoubier
As described in this post, it seems that a reasonable compromise for dealing with Monticello metadata, is that the
*.package/monticello.meta/versionfile be a copy of the Monticello version history when a package is copied into a FileTree repo. Newly created packages (not via copy) would contain an emptyversionfile. The Monticello metadata would not be updated on every commit .... When a package is copied then it becomes necessary to fabricate a revision history to bridge the gap between the original Monticello version history and the present commit - this fabricated version history may account for every git commit since theversionfile was last changed, or simply a new commit referencing the current SHA ...this solution could involve adding some new MCAncestry classes that would record the
urlandSHAof git commits ...making it possible to merge two Monticello packages with a common ancestor somewhere in the git history ... or we could treat the git world as a series of lost mcz files .... If we do support merges involving a specific SHA in github, then new MC classes and support would be required which has impacts on older versions of the images trying to do the merge or even read the packages ... adding fields in the commit comment using JSON or STON containing the fields of interest would probably solve the backward compat problem while allowing newer tools to support such a merge ...Finally we need to resolve the handling of the methodProperties files .. those files are there only for the Monticello meta data and we could drop these files altogether if we fabricated method definitions that picked this information from the latest commit that involved the file ... for performance reasons, I would be inclined to not include this information unless a package was being prepared for export via
copy to repository...I think we should have a bit of free form discussion (i.e., what code can be leveraged from @ThierryGoubier and GitFileTree? and what does @ottobehrens do in his current FileTree implementation?)
One of the issues I'm curious about is how to get past the Monticello/gofer/Metacello? feature that skips loading a version of a Monticello package with a lesser version number ... I know that I have code that addresses this for Metacello (in a separate class for Cypress packages), but we might need to jigger the loader or whatever to make this work but I think that both of you (@ThierryGoubier and @ottobehrens) have dealt with this (and I've forgotten the details)?
I'm not in a hurry to implement this, but I think that it should bump up in priority because it will eliminate the need for the GitMergeTool and make life for the folks working purely in git much simpler, while making it possible for folks choosing not to use git to work with and contribute to projects that have been moved to git/github ...