HgSharp - Mercurial Core in C#
Anton Gogolev
anton.gogolev at gmail.com
Thu Oct 25 07:55:26 UTC 2012
All very valid points, Adrian.
> That may be your impression. I've seen enough developers trapping into
> this kind of false sense of security. People routinely underestimate the
> complexity involved.
That's true and I still have a few parts in Mercurial I just cannot comprehend,
let alone translate to C#.
Let me reiterate, though: HgSharp does _not_ (yet?) implement any kind of
three-way merge logic, transplanting or grafting, MQ, etc. It just reads
and writes revlogs, updates various caches and reads and writes bundles.
I'm also very much aware of how complex Mercurial is, but again: this whole
library has been working fine for us.
> You also split developer resources by forking Mercurial core into
> another language. Those resources could be shared for the benefit of
> everyone if these were combined into a single implementation.
I can barely _read_ Python, so I'm not the one to contribute to Mercurial.
> There are a whole class of potential bugs that you won't even notice.
> HgSharp reading a relatively small set of repositories it has written
> itself has a pretty high chance of being reproducible.
Don't know if this qualifies as a valid counterargument, but we have
"hg verify" running nightly for all our repositories and no problems
were detected yet. And these are all very different repositories: ones
created by HgSharp, ones that were previously managed by hgweb,
imported from Subversion.
But yes, I'm very aware that my selection is not entirely
representative.
> Also, people shouldn't forget that Mercurial's performance-critical
> parts are written in C already - you will hardly be able to beat that in
> performance.
Yep. HgSharp is _significantly_ slower. There's still room for perf
optimizations though.
More information about the Mercurial
mailing list