mercurial's ui is nice, but the storage format sucks, or at least sucked
back when i was using it: no deduplication; every past or present file in
project was backed by similarly named file in storage, under similar
directory tree. from my pov the storage was closer to binary equivalent of
CVS (with some extra magic to provide atomicity) than to something
filesystem-like.

git storage is a proper filesystem, even if it gets hate for other reasons.
it is reasonably easy to understand & interrogate the internals.

there's also fossil scm (unfortunate name clash with plan 9's fossil
archival fs), from the sqlite team, well worth giving a try. by virtue of
using sqlite as backend it's backed by something very filesystem-like, and
is reasonably easy to understand & interrogate the internals. i believe
fossil scm has few external dependencies, being implemented in c by the
rather portability-minded sqlite team.

On Mon, 5 Oct 2026 at 17:46, <[email protected]> wrote:

> I happened to find myself exploring this page:
> https://fqa.9front.org/appendixl.html, (..somewhat painful, ROFL, with my
> hard floors with nails sticking through them..) and came upon this:
>
> "Python 2.5.1 used to be included with the 9front distribution, not
> because anyone loved Python, but because it was required by Mercurial (also
> loved by no one), which was required by Google Code (which shut down in
> 2015). An abject lesson in expediency."
>
> I have been using mercurial for a project because a colleague requested a
> more sophisticated form of version control, and mercurial was the only one
> I couldn't find anybody hating on.  So now, I'm curious: what's so bad
> about it?  I assume this because plan9 has it's own method that is even
> simpler.  And that that being the case, the reason why mercurial exists at
> all is the same as why more people don't use plan9.
>
> Same question for python.
>
> ..I distantly sense that I should clarify things a bit.. -> I have a large
> amount of python code from back when it was convenient, starting from when
> my os journey was at the stage of taking the daring leap from windows to
> linux.  At the time, it was the only option, (from a certain point of
> view), and hasn't given me any trouble.  I've attempted to get information
> on the relative speeds of c code and python code with numerical python,
> with inconclusive results.
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T760946500f0217e4-Me7fa9fb1046b1cf6becec1e7>
>

------------------------------------------
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T760946500f0217e4-M112b115e14857baab0d9f40c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Reply via email to