Re: Core statement on version control systems

[Jörg Sonnenberger <joerg%bec.de@localhost>]

A few small notes.

On 1/4/25 3:52 PM, Taylor R Campbell wrote:
> - For now, linear-history workflow with rebase, just like CVS.
>
>    => We may transition in the future to merge-based workflow
>       integrated with releng automatic testbed, but not today.

IME merge-based workflows generally are just annoying if you actually 
care about the history. They are not necessary for CI either.

> > * Performance implications of the desired VCS system, especially
> >    for hosts with low or moderate amounts of memory.
>
> hg can operate in about 512 MB of working memory, without the evolve
> extension for revising work-in-progress development topics.  (With the
> evolve extension, requires about 3 GB.)

Primary concern is the initial clone as that essentially requires the 
full directory tree in memory. The only commits we have that touch more 
then 10% of the tree are the branch merges right now and that's mostly a 
side effect of RCS ID changes. So memory use beyond initial clone isn't 
that much of a problem.

There are two choices for hg:
- regular clones are more compatible across client versions
- regular clones are much smaller
- stream clones require significantly less client CPU time (they are 
kind of a tarball send), they should be downlink-bound if the bundle 
itself is cached or the link to anonhg is actually fast.

> XXX TBD: Test whether remotefilelog reduces memory usage.

When I tested it a few years ago, it actually requires significantly 
more memory. I don't expect anything to have changed in that regard.

> ** flaky network issues
>
>    `hg clone' and `hg pull' are able to automatically use bundles
>    (though not incrementally) announced via hash and external URL by the
>    remote server, so they can safely be delivered through the CDN
>    (hashed bundle references are new in Mercurial 6.9).

I haven't given up on doing this for the static bundles yet.

> 4. [SECURITY]
>     XXX Future change: auditlog configured to record who pushed what
>     XXX (currently using deprecated pushlog instead)

One note here: one of the motivations here is that we can't push the 
pushlog records to anonhg ATM.

>     (c) [SECURITY] require committer name match ssh login

I would actually not do that. The committer of a patch should be the author.

> **** anonhg.NetBSD.org (alias anongit.NetBSD.org)
>
> 1. clone of hg.n.o repositories with same public/draft/all division
>
>     Physical layout:
>
>     XXX Why do we have /hg/src-all in addition to /hg/.joined/src?
>     Something about hg.n.o's hg push for the conversion needing
>     different configuration (.joined) from the public view (-all)?

We don't want to trigger any of the view restrictions when doing this 
mirroring.

> 2. anonymous read-only access via hg over ssh as user `anonhg'

I would strongly prefer to *not* do this. ssh-access for readonly users 
is inferior to https from a performance perspective and

>     => [SECURITY] This is necessary so we can ship the ssh host key
>        fingerprint with NetBSD instead of just relying on HTTPS CAs for
>        https://anonhg.n.o.

If this is the only reason, there are IMO better options. We can publish 
a CA root and use name-based CA pinning for example 
(hostsecurity.anonhg.netbsd.org:verifycertsfile) without compromising 
regular certificate and key rotation as mandated by modern CAA practice.
The server can provide multiple trust chains, so clients using the 
regular web trust roots will pick LE and others the TNF CA.
> **** audit trail [SECURITY]
>
> We can use a pretxnchangegroup hook to require the ssh login name to
> match the author name on any changesets pushed to the repository.  This
> provides the same audit trail as CVS.  No regression.

I don't see the point of this and it would break sensible collaboration 
models. E.g. if I send you some changes out of band to test, you should 
still be possible to push them to the main repo.

> XXX TBD: hg auditlog (replacing hg pushlog) to record who pushed what
> without requiring the authorship to match, so we can more easily credit
> outside contributors.

pushlog does the same, it just can't be replicated as easily. auditlog 
can record the SSH key used, which could be useful for forensic purposes.

> **** email for commit messages
>
> We can use the `notify' extension to send commit notifications by email
> to source-changes@.
>
> XXX Decide how to filter revisions to existing work-in-progress
> changesets.

The logic tries to provide threading for rebased changes, but it doesn't 
do anything like "skip the mail if there is no change to the last mail 
beyond the parent". It was written under the assumption that no records 
of what was mailed so far exists, making it hard to anything smarter.

>     - With pkgsrc cross-builds, we can build mercurial packages for
>       every platform, even if we don't currently do bulk builds for all
>       platforms.

Except VAX.

> > * An estimated time-line of the conversion, together with a list
> >    of people responsible for it and their respective tasks.
>
> Phase 1: February 2025.
> Phase 2: March 2025.
> Phase 3: April 2025.

Note that my time commitments before March are limited and sporadic for 
both work and non-work reasons.

Joerg