• Contact: tech-repository

IMPORTANT: This project was completed by Joerg Sonnenberger. You may still contact the people above for details, but please do not submit an application for this project.

Background and description

NetBSD is one of the first projects to use internet-available source control. It has been using CVS since the very beginning of the project (over 21 years) and the repository is vast.

NetBSD also hosts the pkgsrc repository which has many small files, many "imports" and other technical challenges associated with VCS.

NetBSD also has various small internal repositories (like this wiki).

During the last twenty years tooling has improved and popular developer culture has shifted to new workflows.

The purpose of this project is to identify:

• existing 'workflows' in common use among developers
  • (example): hgnb
• existing 'tooling' within NetBSD the organization
  • how much memory/disk is required to host NetBSD?
  • how are backups performed?
  • can the tools be cross-build?
• security requirements like
  • how do we validate commits?
  • how do we ensure commits originated from developers?
• release engineering requirements such as
  • how does a pullup request work?
  • how do we ensure the correct files are included in the correct release branches?
  • how do we checkout a release branch
  • how do we look at the history of a release branch
  • how do we get different revisions of a file on a branch

major parts of the technical work like "how to convert FROM CVS to git/hg/fossil" has already been done, which is why we are able to now ask "how would the project continue to function?"

Our decision matters

You're reading this because you care about the future of NetBSD and you understand that good tools act as a force multiplier.

Our decision is not obvious

If it were, we'd have made it already (and wouldn't be disagreeing so persistently about which one it needs to be ;-).

Our decision needs to be about the whole elephant

We all understand the basics of using source control. This level of understanding is necessary but not sufficient to make an informed decision about whether to migrate any or all of NetBSD's repositories to another VCS, and if so which, or how.

Our choice of VCS carries implications not only about how developers hack on NetBSD, but also about how non-developers contribute and become developers, and how Project sysadmins keep our valuable code secure. Therefore, any choice of VCS other than the default (sticking with CVS for a while longer) necessarily implies that as a group, we all need to learn how we're going to do what we expect to need to do. Not all of this learning needs to happen before we can make a reasonably confident decision for our Project. But if we want to arrive at consensus, much of it does.

There is no available choice of VCS that entirely avoids tradeoffs for us. Therefore, to choose intelligently, we must first consider all the tradeoffs we can think of, then decide which ones we can live with and which we can not.

Our decision needs to be made together

We're a community. The only way a complicated, interconnected set of changes like this can be implemented is for us to arrive at rough consensus that some particular VCS:

• is sufficiently well suited to our project's needs in theory,
• is sufficiently easily adapted to our needs in practice,
• has a sufficiently fail-safe migration plan,
• is worth the effort to switch, and
• has volunteers to do the work.

How you can help, right now

What are some considerations you think are important? Are they listed here? If not, edit this page and add them.

Some previously collected considerations

• tech-repository

Considerations

Humans

• People who administer Project resources
• People who administer release branches
• People who administer security updates
• People who can commit directly to NetBSD
• People who can't commit directly to NetBSD

Machines

• Some ports/machines are memory constraint or rather slow (by todays standards), a VCS different than CVS should be able to used on these machines as well. (e.g. git has parameters to tune memory usage, and there exists git-cvsserver which allows a git repository to be accessed using a CVS client)

Workflow / Commonly used actions

• Checkout the whole tree
• Checkout a partial tree (or subdirectory)
• Create a branch
• Merge a branch with the head/main branch
• Create a tag
• Commit local changes to a branch
• Commit local changes to the main branch
• Revert a commit
• Fix a commit message
• Create a diff between two versions of a file

Tools

• Command line tool
• Web based source code browsing and maybe riffing (in the style of e.g. trac)
• Availability on different platforms (pkgsrc is not NetBSD only)