Also, I'm torn at this point between the thoughts along the lines "selection of modern DVCS spoil us" against "damn, why they there is no clear popular + works-for-everything thing", but it's probably normal, as I have (or had) similar thoughts about lot of technologies.
Feb 07, 2012
May 02, 2011
- watching fossil-path with inotify(7) for IN_MODIFY events (needs pyinotify for that)
- checking for new revisions in fossil (source) repo against tip of a git
- comparing these by timestamps, which are kept in perfect sync (by fossil-export as well)
- exporting revisions from fossil as a full artifacts (blobs), importing these into git via git-fast-import
It's also capable to do oneshot updates (in which case it doesn't need anything but python-2.7, git and fossil), bootstrapping git mirrors as new fossil repos are created and catching-up with their sync on startup.
While the script uses quite a low-level (but standard and documented here and there) scm internals, it was actually very easy to write (~200 lines, mostly simple processing-generation code), because both scms in question are built upon principles of simple and robust design, which I deeply admire.
usage: fossil_echo [-h] [-1] [-s] [-c] [-b BRANCH] [--dry-run] [-x EXCLUDE] [-t STAT_INTERVAL] [--debug] fossil_root git_root Tool to keep fossil and git repositories in sync. Monitors fossil_root for changes in *.fossil files (which are treated as source fossil repositories) and pushes them to corresponding (according to basename) git repositories. Also has --oneshot mode to do a one-time sync between specified repos. positional arguments: fossil_root Path to fossil repos. git_root Path to git repos. optional arguments: -h, --help show this help message and exit -1, --oneshot Treat fossil_root and git_root as repository paths and try to sync them at once. -s, --initial-sync Do an initial sync for every *.fossil repository found in fossil_root at start. -c, --create Dynamically create missing git repositories (bare) inside git-root. -b BRANCH, --branch BRANCH Branch to sync (must exist on both sides, default: trunk). --dry-run Dump git updates (fast-import format) to stdout, instead of feeding them to git. Cancels --create. -x EXCLUDE, --exclude EXCLUDE Repository names to exclude from syncing (w/o .fossil or .git suffix, can be specified multiple times). -t STAT_INTERVAL, --stat-interval STAT_INTERVAL Interval between polling source repositories for changes, if there's no inotify/kevent support (default: 300s). --debug Verbose operation mode.
Apr 25, 2010
Repository, syncer and some instructions are here.
Thought I'd give google some keywords, should someone be looking for the same thing, although I'd probably try to push it into paludis and/or "unavailable" repo, when (and if) I'll get a bit more solid grasp on exherbo concepts.
Apr 17, 2010
Git is a great help in these tasks, but what I feel lacking there is a first - common timeline (spanning both into the past and the future) for all these data series, and second - documentation.
Solution to the first one I've yet to find.
Documentation for anything more than local implementation details and it's history is virtually non-existant and most times it takes a lot of effort and time to retrace the original line of thought, reasoning and purpose behind the stuff I've done (and why I've done it like that) in the past, often with the considerable gaps and eventual re-invention of the wheels and pitfalls I've already done, due to faulty biological memory.
So, today I've decided to scour over the available project and task management software to find something that ties the vcs repositories and their logs with the future tickets and some sort of expanded notes, where needed.
It just looks like a completely wrong approach for my task, yet I thought that I can probably tolerate that if there are no better options and then I've stumbled upon Fossil VCS.
- Tickets and wiki, of course. Can be edited locally, synced, distributed, have local settings and appearance, based on tcl-ish domain-specific language.
- Distributed nature, yet rational position of authors on centralization and synchronization topic.
- All-in-one-static-binary approach! Installing hundreds of git binaries to every freebsd-to-debian-based system, was a pain, plus I've ended up with 1.4-1.7 version span and some features (like "add -p") depend on a whole lot of stuff there, like perl and damn lot of it's modules. Unix-way is cool, but that's really more portable and distributed-way-friendly.
- Repository in a single package, and not just a binary blob, but a freely-browsable sqlite db. It certainly is a hell lot more convenient than path with over nine thousand blobs with sha1-names, even if the actual artifact-storage here is built basically the same way. And the performance should be actually better than the fs - with just index-selects BTree-based sqlite is as fast as filesystem, but keeping different indexes on fs is by sym-/hardlinking, and that's a pain that is never done right on fs.
- As simple as possible internal blobs' format.
- Actual symbolics and terminology. Git is a faceless tool, Fossil have some sort of a style, and that's nice ;)
Yet there are some things I don't like about it:
- HTTP-only sync. In what kind of twisted world that can be better than ssh+pam or direct access? Can be fixed with a wrapper, I guess, but really, wtf...
- SQLite container around generic artifact storage. Artifacts are pure data with a single sha1sum-key for it, and that is simple, solid and easy to work with anytime, but wrapped into sqlite db it suddenly depends on this db format, libs, command-line tool or language bindings, etc. All the other tables can be rebuilt just from these blobs, so they should be as accessible as possible, but I guess that'd violate whole single-file design concept and would require a lot of separate management code, a pity.
But that's nothing more than a few hours' tour of the docs and basic hello-world tests, guess it all will look different after I'll use it for a while, which I'm intend to do right now. In the worst case it's just a distributed issue tracker + wiki with cli interface and great versioning support in one-file package (including webserver) which is more than I can say about trac, anyway.