Re: irt: Re: Core statement on version control systems

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Dec 01, 2025 at 02:43:20PM -0800, Greg A. Woods wrote:
 > First off I want to thank you very much for writing this and your other
 > recent reply!

YW :-)

sorry it took so long; that's just what my life is like lately...

 > > : Is there a publicly available rationale document?
 > >
 > > Rationale for moving away from CVS? The rationale for that is obvious.
 > 
 > Not a reason for doing so, but a "rationale".  I think Andrew was asking
 > for something like what Warner wrote about the FreeBSD changeover to git.

renames and atomic commits were the primary motivating factors I
remember early on. CVS's performance horrors joined them once it
became clear just how much useless I/O CVS does.

 > I think I understand much better about what you are "complaining" about
 > with Git's rename handling.
 > 
 > However you didn't really answer the direct question, i.e. is it a real
 > requirement for the NetBSD repository?
 > 
 > I agree with all the points you made about taking care around renaming
 > files and committing those changes.  I would posit that they make sense
 > no matter how smart or dumb the VCS is.

Yes and no. You should always divide renames and content changes into
separate commits; or at least, no tool I'm aware of readily handles
the results if you don't, e.g. for annotate.

However, it's only git where you need to be super careful about
merging or rebasing across renames, and only git where it's prudent to
limit the number of files renamed in a single commit. hg just doesn't
have those problems.

There's two parts to this issue: one is detecting renames by
comparison at commit time vs. having them indicating explicitly with a
"mv" command. I think it's much more reliable and robust to have
explicit "mv" (and "cp" too), because if you rename a whole bunch of
very similar files in one commit it's possible for the detection
heuritsics to go off the rails. But in ordinary circumstances it
doesn't make much difference.

The other part is whether renames are recorded in commit metadata or
whether the information is thrown out, and the heuristics are
re-engaged later to guess and maybe get unpredictably different
results. _That's_ the problem with git's approach.

Anyway, we have a thirty year backlog of pending tree reorganizations.
While we've now done a fair number with cvs add/remove, that's mostly
been limited to the most critical and least invasive changes, and
mostly of 3rd party stuff where the history isn't a super important
asset.

As I posted last weekend in another thread, cleaning up the mess with
libc and kernel headers involves mass renaming, and does it right in
the center of everything. That requires real rename support, and
that's a big part of why it hasn't happened anytime in the past 15+
years since I first started talking about it.

So yes, it does matter and yes, we do need it.

 > On the other hand if reorganising files and directories is highly
 > desired then what does it really matter if the history of those files is
 > harder to follow?  I.e. pick a priority and stick to it!

With non-broken tooling it wouldn't get harder at all. Both hg and git
are lacking on this from the UI perspective.

 > >  :: - storing the identity of long-running branches in the history
 > >  :
 > >  : Can you expand on this?
 > >
 > > In git, you can find the merge commit, and it has two ancestors, and
 > > there's a diamond in the commit graph. But you can't tell from the
 > > repository metadata which side of the diamond was the trunk and which
 > > was the development branch. You have to read and interpret the commit
 > > messages. You also can't tell which development branch it was.
 > 
 > I would just say that's what tags are for.  :-)

You can, but it's messy and you shouldn't have to.

 > Also it's trivial to embed the branch name into every commit message.

That doesn't help automated processes very much, unless it's _really_
always there.

 > I find Git branches almost unusable without making branch base tags
 > anyway, so much so I'm thinking of figuring out how to automate it.

git branches _are_ pretty well unusable for traditional branch tasks :-|

-- 
David A. Holland
dholland%netbsd.org@localhost