filetree
filetree copied to clipboard
dalehenrich
Monticello->filetree converter
What would be absolutely amazing would be a tailor-like tool to convert an existing Monticello repository for a package into a filetree repo under git.
Gitocello does something like this: when you say "track using git" it walks all extant mczs, progressively putting each under version control.
Frank,
Not quite sure what tailor does, but you can do the "conversion" right now by opening a FileTree repository and use the Monticello copy command to copy an mcz file into the FileTree repository and the mcz file is converted...
Ah... it would walk the mcz files and copy .. for git you'd want to do that for sets of packages (Metacello configuration files) to get the state of the project at each version recorded correctly .... but yes that would be a cool tool to have.
OK, I can take a hint :) Maybe I should see what I can take from Gitocello, which does just this - walk the history from the initial package and dump it in git. Only it uses the chunk format where we'd use filetree.
Ah, I think you're talking about walking the ConfigurationsOf? That's pretty coarse-grained. To a first approximation of correctness you could
- walk the ConfigurationOf versions and
- find out the package version and test package version
- walk from the child of the last touched version (or the initial version) to that version for both packages (or sets of packages), adding each version to the repo as a separate commit
Right but for multi-package projects, the only way to know what package versions work together is to go with the ConfigurationOF...
If you create a separate git repository for each mcz file then you'd be able to duplicate the mcz history in git ...
As soon as you go multi-package you can't rebuild a meaningful history of the collection of mcz files in the same git repository without knowing which versions of each mcz are intended to be used together ... which is where configurations enter the picture...
Dale
----- Original Message ----- | From: "Frank Shearar" [email protected] | To: "Dale Henrichs" [email protected] | Sent: Monday, August 6, 2012 10:53:09 AM | Subject: Re: [filetree] Monticello->filetree converter (#57) | | Ah, I think you're talking about walking the ConfigurationsOf? That's | pretty coarse-grained. To a first approximation of correctness you | could | | - walk the ConfigurationOf versions and | - find out the package version and test package version | - walk from the child of the last touched version (or the initial | version) to that version for both packages (or sets of packages), | adding each version to the repo as a separate commit
It has always bugged me that there is no correlation between versions of different mcz packages that are supposed to work together, but then I guess that's why I invented Metacello:)
I came up with a ridiculously complicated scheme to reconstruct the history, but there's a much easier way: treat the thing like a merge operation: walk the package histories in parallel, and merge them in order where "in order" uses commit timestamps. Result: a single time-ordered sequence of code changes.
Tagging the repository is left as an exercise for the reader :) (In the future, with tighter git integration, I can imagine a ConfigurationOf browser that lets you bump versions automatically (in the sense that MyMultiPackageProject version bumps and creates a configuration for the latest versions of contained packages, and would tag the repo.)
The merge scheme does sound like a technique that will allow you to reconstruct the commit history for multiple packages.
There is still the issue of Monticello branches ... both explicit using the packagename.branchname scheme and implicit when a package is renamed or split into pieces ... the explicit branch should be straightforward ... the implicit branching is more difficult (think OSProcess with the two sets of packages).
If configurations exist, then you can use the configuration versions to create the tags ... in fact in the git world, the Metacello configurations boil down to a cross-platform tagging mechanism as git takes the burden of coordinating the multi-package commits...
https://github.com/frankshearar/Control <-- I just ported my repo from a local copy of http://ss3.gemstone.com/ss/Control.html (except the README of course). I won't keep you in suspense for too long: I just need to neaten up the (rather short!) script before I publish it. It doesn't handle branches, but I'm kind've semi-OK with that, at least for the moment.
Frank,
The commit history looks very cool!
It is very tempting to rebuild the Metacello repository using your script so I can have the early history included as well ...
Let me first tweak the conversion to preserve the original timestamps. I'll do that tonight or over the weekend; it's just pulling the date info out the MCVersionInfos and using --date=foo on the command line. I'll probably nuke and redo the Control repo, because I like having the original timestamps.
Do you make heavy use of (explicit) branching in the Metacello repo? I haven't tried it yet but I think that just by pulling the branch name put of the MCVersionNames I can just use the existing algorithm and add an extra step, changing to the appropriate branch (or master if no branch is present).
Oh, I won't be converting Metacello real soon ... probably this fall sometime as I get close to a 1.0 release ... original timestamps would be real cool!
I've done a few very minor branches in Metacello itself and if the branches are simply merged into the timeline that'd be fine.
There's very little branching done in Monticello because it's just not that well supported:)
OK, so if I did branching support, Metacello wouldn't be a great test case :)
It's clearly not a fully polished project, and requires some things that haven't been released yet (I've sent Tim Felgentreff some extensions to Gitocello, and I wrote a SequenceableCollection >> flatten which Squeak doesn't have), but it works nicely - take a look at the timestamps in the Control repo now!