On Mar 19, 2015, at 5:52 PM, Abilio Marques <[email protected]> wrote:
>
> I've toyed with the idea of writing a "shim" so fossil can be used in place
> of git or subversion.
I speak only pidgin Git, so I wouldn’t like to speculate about how difficult
such a shim would be to write.
I can, however, speak to the svn case. I have used Subversion heavily for
about a dozen years now, so I can pretty confidently predict that you’re going
to run into a bunch of areas where the semantics of Fossil and Subversion
differ enough to make building such a shim tricky, and in places actually
difficult.
Here are the differences that immediately occur to me:
1. svn uses a monotonically-increasing revision number for the whole repository
as the unique identifier for each checkin. Fossil uses cryptographic hashes
instead. This affects every command in both systems that take an -r flag, and
more.
(“More” because Fossil doesn’t always use -r to specify a checkin. Fossil is
somewhat of a bicameral mind on this point: sometimes you use -r, and other
times you just give it as a bare parameter.)
For the same reason, I don’t know how you’d implement an svnversion wrapper in
terms of Fossil.
2. Fossil branching and tagging are baked into the database schema; there’s
only one way to do it.
In Subversion, branching and tagging are a mere *convention* built on top of
the svn copy command, and there is no requirement that your copy target be
somewhere under the repo’s branches or tags directories; that too is just a
convention.
I don’t think you can actually emulate the full scope of the svn copy command
in terms of Fossil. There are things you can do with that command that do not
map neatly to fossil tag and branch commands.
3. fossil timeline is not quite the same thing as svn log.
First you have to decide if you want to translate the output formats so that
it’s parseable by tools that know how to read svn log output.
Then you have a deeper problem, which is that the two commands simply don’t
entirely overlap in their capability.
Some svn log commands will be straightforward to translate into fossil timeline
commands:
svn log -r{2014-12-25}:HEAD
is the same as:
fossil timeline after 2014-12-25 -n 0
But, svn also lets me give an arbitrary log endpoint, which fossil timeline
doesn’t:
svn log -r{2014-12-25}:r1234
How will your shim cope?
4. svn does one-step mv and rm operations. Fossil currently requires a
separate OS-level mv or rm to accompany the Fossil command in order to make the
file tree consistent with the repo.
I’ve advocated for this to change, though it’s looking like if something along
this line does happen, it won’t be to make Fossil behave exactly like svn, but
perhaps more like Monotone instead.
5. svn ci is not quite the same thing as fossil ci. Perhaps “fossil ci .” is
close enough for your purposes. (i.e. Subversion checks in only files in the
current directory and its children, by default.)
6. svn allows sub-repo checkouts. Fossil doesn’t. (Yet.)
7. There is no equivalent to svn [un]lock in Fossil. (Praise Ritchie!)
8. Emulating svn merge in terms of fossil merge amounts to taking a simple and
straightforward interface and complexifying it.
9. svn doesn’t even blink if you try to check in a binary file. Fossil copes
just fine with binary files, too, but by default it second-guesses you whenever
you do it with a file that isn’t on its glob whilelist.
10. svn info more or less combines what Fossil implements separately via info
and finfo. I think it might be tricky to work out which Fossil command to call
for a given set of args to your svn wrapper.
11. svn stat and fossil stat are conceptually the same thing, but their output
formats are quite different.
12. fossil open kind of overlaps the effects of svn co and svn switch, but not
entirely.
13. Most of the svn prop{get,set,edit,del} properties do not exist in Fossil:
svn:ignore: Fossil has the ignore-glob setting, but it’s very much not the same
thing. Fossil and svn are almost inverses in the way they handle file
ignorance. (Ignoration? Ignorification?)
svn:keywords: Fossil doesn’t do RCS/CVS-like keyword substitution at all, on
purpose.
svn:executable: A similar per-file property exists in Fossil, but it’s more of
an implicit property. To make the shim behave *exactly* like svn, you’re going
to have to defeat Fossil’s implicit use of the file’s modes to implement this
property.
svn:eol-style: Fossil doesn’t do CRLF translation, ever. I think those
interested in using such a shim will be a self-selected set of people who have
a greater-than-average interest in having such a feature than those willing to
just switch to Fossil. You may be asked to emulate this behavior on top of
Fossil.
svn:mime-type: The “doc” URL handler in Fossil has a hard-coded implementation
of this, which probably obviates the need to emulate this property, but perhaps
someone needs the flexibility of per-file MIME types.
svn:externals: No equivalent in Fossil, as far as I can tell.
svn:needs-lock: No equivalent in Fossil, since there is no locking.
14. fossil ls and svn ls aren’t quite the same thing. The semantic differences
are mostly covered above in terms of other commands, so just take it as a fact
already in evidence.
I’m sure I’ve missed a whole bunch of other differences. Subversion and Fossil
really are quite different. Your shim will have to be quite thick in places in
order to provide a convincing illusion.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
