2017-03-01 13:15 GMT+01:00 Pierce Ng <pierce@samadhiweb.com>:

On Tue, Feb 28, 2017 at 04:23:12PM +0100, Thierry Goubier wrote:
> 2017-02-28 1:19 GMT+01:00 Pierce Ng <pierce@samadhiweb.com>:
> > I have written a simple integration of FileTree with Fossil to avoid the
> Congratulations! This was one of my objectives with GitFileTree: open up
> the Pharo infrastructure to other DVCS such as Fossil.

And indeed runOSSubprocessFossilCommand is basically runOSSubprocessGitCommand,
so thank you for GitFileTree.

I've only implemented #basicStoreVersion: and it is simply this:

�� basicStoreVersion: aVersion
�� super basicStoreVersion: aVersion
�� (MCFossil new repoDir: self directory fullName)
�� addRemove;
�� commit: aVersion info message

The last 3 lines is of course just the Smalltalk way of saying
"fossil addremove; fossil commit ..."

Currently that's all it does.

Great!

��

> How does Fossil handles merging the FileTree format?

Just to be sure I get your question, do you mean whether FossilFileTree sees
the changes if I edit the .st files using vi, say?

No, it is a bit more in depth. FileTree, by default, will save some metadata with the packages (method timestamps, package version history) and this, with git, creates conflicts when merging (and cherry picking and a few other operations). GitFileTree introduced a variant of the format, called metadata-less, to avoid that and recover the metadata from the git history itself (and convert it to Monticello).

��

Right now, after committing in Monticello Browser, when I click 'refresh' or
'changes' everything shows up as new again. That can't be right. Which part of
GitFileTree deals that?

The all new again is the default FileTree approach.

In GitFileTree, it recovers all the versions with git log and rebuild them for the repository browser. It is done starting with MCFileTreeRepository>>#gitVersionsForPackage:, then MCFileTreeGitRepository>>#getVersionsForPackageDirectoryName:, tied with a specific class to register the data for all entries (GitFileTreePackageEntry -> other repositories uses only strings to track all the versions). In there you also see the bridge which converts from git log metatadata to Monticello metadata (MCVersion and ancestry).

Side question then: is Iceberg factoring out some of that out of GitFileTree, since it supports/supported the libgit and GitFileTree backends? Factoring out could also be of benefit to Fossil.

Regards,

Thierry

��

Pierce