Hi all,
I hope its ok to post a message on this topic. I read some threads about
this from last December's digests after joining the fossil-dev group today.
For my needs, git cross-integration is a requirement. When I worked at
Microsoft as JavaScript and Powershell Architect I tried to have some
teams use fossil. While fossil had some clearly superior features and
design elements, the lack of seamless out-of-the-box cross-collaboration
mechanisms with other repository scm systems became a non-starter.
I made a long post about an hour or two ago on the general mailing list
of things I had done for the last week to upgrade fossil to support
various things for team collaboration use. One of my requirements was to
enable seamless integration with git for those who I work with or who
cannot even use fossil and need to cross-share repo changes between
fossil and git.
My work on that is still an in progress thing. But here are a few things
I found useful.
1) I grabbed the lastest fossil repo, turned on indexing of all the
content, and saw the changes made for fast git interchange marks.
2) Modified my fossil build sources to transparently manage issues with
trunk and master naming and renaming. Especially when creating new repos.
3) Set things up so that all the file name associations for fossil repos
could be and were linked to SqliteBrowser app for our team developers to
quickly validate any issues. Specifically making .fslckout the default
on all platforms.
4) Worked with one of our devs to set up nodejs and grunt tasks to
monitor changes and migrate them between a git-repo and a fossil-repo.
Step 4, while a work in progress, suggests that, like TCL integration or
FUSE/DOKAN (on Windows) integration etc. One path to git support could
be the presumption of git being installed on a developers machine, and
then have fossil transparently exec/issue commands to git for any
operations. This approach, using temp files (as fossil loves to do), has
also worked to make it pretty easy to use git to pull down a repo, tell
git to extract its contents, create a fossil repo, import the contents,
and subsequently maintain syncing them. As well as doing the reverse of
creating a git repo, exporting fossil change records, importing them
into the new repo, and then as in the first case keeping them in sync.
We currently can quickly do item 4 aspects with manual assists, and I am
thinking about whether to build those automated git-driver steps into
fossil (via TH1) or just use our nodejs/grunt facilities.
p.s., I modified our fossil implementation to support server side TH1
wiki-scripts with new wikiedit interface. That was essential to enable
supporting team members to author reports, custom pages, and make use of
the rich sqlite features available.
David Simmons
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
