I haven’t announced a reposurgeon release on the blog in some time because recent releases have mostly been routine stuff and bugfixes. But today we have a feature that many will find interesting: reposurgeon can now read BitKeeper repositories. This is its first new version-control system since Monotone was added in mid-2015.
Those of you who remember the BitKeeper flap of 2005 might assume some fearsome magic was required, but no. BitKeeper has gone open source and now has a “bk fast-export” subcommand, so adding read-side support was pretty trivial. In theory the write-side support ought to work – there’s also a “bk fast-import” that reposurgeon uses – but the importer does not work well. It doesn’t seem to handle tag declarations, and I have core-dumped it during basic testing. I expect this will be fixed eventually; BitMover has a business incentive to make imports easy, after all.
While reposurgeon has your attention, I guess I should mention another revent development. The svncutter tool that I wrote back around 2009 is back, as “repocutter”, and now part of the reposurgeon distribution with improved documentation. There are some cases of Subversion repositories holding multiple projects that it turns out are better handled by slicing them apart with repocutter than by trying to do the entire dissection in reposurgeon.
Yes, there are still some pending bugs in weird Subversion cases. I decided to ship a release anyway, deferring those, because read support for BitKeeper seemed important enough. I believe that makes reposurgeon’s coverage of Unix-hosted version-control systems about as complete as is technically possible.
Routine, huh? That’s unusual.
I believe the date is wrong; otherwise, you did this a year ago and are only telling us now for some mysterious reason – probably as part of the Eric Conspiracy’s unfathomable plan for world domination. ;-)
Reposturgeons have the best caviar.
Time for an O’Reilly book? https://upload.wikimedia.org/wikipedia/commons/b/b8/Acipenser_oxyrhynchus.jpg
All our times have come
Here but now they’re gone
C doesn’t fear the repo
Nor does perl, the ADA or python, you can be like they are
Come on baby, don’t fear the repo
Baby take my code, don’t fear the repo
We’ll be able to try, don’t fear the repo
Baby I’m your tool
SCCS is done
Here but now they’re gone
RCS and CVS
Are together in eternity, RCS and CVS
Forty more repos everyday, like RCS and CVS
Forty more projects everyday, redefine happiness
Another forty more coming everyday, We can be like they are
Come on baby, don’t fear the repo
Baby take my code, don’t fear the repo
We’ll be able to fly, don’t fear the repo
Baby I’m your tool
Bugs are two then one
Here now but also gone
Came the last night of madness
And it was clear it wouldn’t build.
Then the commit was and the code appeared
The bugs were factored and disappeared
The compile flew then exe appeared, saying don’t be afraid
Come on baby, and she had no fear
And she ran the code, then they started to write
They looked backward and said goodbye, she had become like they are
She had taken his code, she had become like they are
Come on baby, don’t fear the repo
I should probably apologize for that, but I won’t.
>I should probably apologize for that, but I won’t.
I’m…actually kind of awestruck. You wrote a filk. About reposurgeon.
I’d say that I don’t expect anything weirder to happen to me in the next month, but that would certainly invoke the Dread God Finagle (may his gaze be averted).
s/Nor does perl, the ADA or python/Nor does the Perl, the Python or Go/
s/the commit was and/the commit was made and/
> > I should probably apologize for that, but I won’t.
> I’m…actually kind of awestruck. You wrote a filk. About reposurgeon.
Perhaps we should get Tom Smith to sing it for us at Penguicon, unless that falls immediately into your class of “anything weirder to happen to me in the next month”. Don’t want to give Finagle any ideas, y’know.
Also – will there be a FoA&D party this year?
>Also – will there be a FoA&D party this year?
There will be. We applied for party room status today,
You write “I believe that makes reposurgeon’s coverage of Unix-hosted version-control systems about as complete as is technically possible.”
I note for the record Fossil SCM, at https://www.fossil-scm.org/ (which will expand to https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki). See also https://en.wikipedia.org/wiki/Fossil_(software) for a summary overview.
Hope this is of some use, interest. Thanks for your time. Be well.
>I note for the record Fossil SCM
We have read-side Fossil support. I don’t know that it has been tested, but nor do I have any bug reports.
Fair enough. Is it through a X-to-git type shim as an intermediary (tho on second thought perhaps that doesn’t make any sense, considering?), or directly from a Fossil repository, e.g. reposurgeon understands the Fossil file format, semantics, etc?
Is reposurgeon aware of Fossil 2.0/2.1 and forward, where there is a non-backwards-compatible change to the file format (change from using SHA1 to SHA3-256 hashes for new checkins, at least for new repositories and eventually even for already-existing repositories, due to advances in the ability to make intentional collisions of SHA1 hashes)?
I can see where writing files, checkins, etc to a repository would be more difficult. Presumably at this point in time if you did it it would be via calls to the fossil command line client (that’s how I would attack it anyway). If and when fossil-as-a-library (“libfossil”) ever comes to exist as a real working thing (it does exist now, but is not feature complete AIUI, and work on it has stalled due to physical injury of the primary developer of it), that would quite possibly be a better way to go.
>Fair enough. Is it through a X-to-git type shim as an intermediary (tho on second thought perhaps that doesn’t make any sense, considering?), or directly from a Fossil repository, e.g. reposurgeon understands the Fossil file format, semantics, etc?
Simpler than that. Fossil has a fast-export command. I assume it is correct. This reduces the “read Fossil” problem to the “read Git” problem.
I would consider that a “shim as an intermediary” approach, in that *IF* there is information kept by Fossil which would not make sense in a git context (I don’t offhand know recall if there is or not), presumably any such information would not be made available via the fast-export command *even* *if* it might be of use interest to reposurgeon. Whereas being able to natively read Fossil repositories would insure that all possible information kept by Fossil would be available to reposurgeon. (I can understand why you would not want to go to the trouble of that, of course; in the greater scheme of things Fossil *is* fairly niche.)
Of course, if this is the case (fast-export not transforming some information available within Fossil into git because it’s not useful in a git context) it would also affect things like useful Fossil-git-Fossil round trips; if fast-export and or fast-import lose information in the process of conversion which is available in the original Fossil repository, then obviously the new version of the repository won’t, can’t, have this information! But, that’s not your problem, not least of which is because you do not at this time write Fossil repositories with reposurgeon.