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

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Wed, 8 Oct 2025 at 19:52, David Holland <dholland-tech%netbsd.org@localhost> wrote:
>
> On Wed, Sep 24, 2025 at 05:39:40PM -0500, Constantine A. Murenin wrote:
>  > > spouting off. It's all been hashed out a bazillion times before
>  > > because new git advocates appear regularly.
>  >
>  > Where exactly has it been hashed out a bazillion times?
>  >
>  > http://wiki.netbsd.org/mailing-lists/tech-repository/
>
> Well, for starters you might try looking at the mailing list archive
> and not some random decade-old wiki page.
>
> But, to be fair, while tech-repository was created to sequester this
> argument, that hasn't been super successful and some of the copies of
> the argument are elsewhere.

Is there a publicly available rationale document?  Something we can go
back to in 10 years and say, well we got that right, but wow we got
that wrong :-)

I'm now looking back through archives at GCC and FreeBSD and I'm
struggling to find such a document.  Any one?
My gut feeling is the drivers were:

- cvs sucks, we need to change
- marketing tells us that subversion is CVS with the problems fixed
- git isn't yet mature and perhaps a bridge too far (I believe that is
correct for GCC)
- there's someone highly motivated to do the conversion

Whatever discussion there was, it seems to have completely missed or
dismissed the lack of a guarenteed commit order and an unworkable
branch/tag model.

What I do know is that gdb+binutils did a wait and see, followed
quickly by Yea? Nah!  To its credit NetBSD made a similar choice.

> That list is missing at least two critical points where git falls
> short:
>    - storing file rename data

Is that a real requirement?  Or a hangover from a better CVS wishlist?

One of Subversion's grand claims to fame was tracking file renames and copies.
In my opinion that had little to do with change sets and more to do
with the nonexistent branch model - where a branch or tag was simply
`cp -r src tags/release-1` - for these commits to be efficient they
had to track src/dest.

What should matter is that the changeset correctly transforms the
entire body of work.

>    - storing the identity of long-running branches in the history

Can you expand on this?