Version control in FreeBSD(Subversion, CVS, Perforce, and Git)

Hello. I posted this thread because I want some advice about version control system.

Subversion, CVS, Perforce, and Git. Which one is the fastest and what are the advantages and disadvantages of each one?

I can use Perforce and Git and I heard that there was a FreeBSD repository for Perforce once. Why is it closed now? And can I use the latest version of it on FreeBSD?

Also, I read that FreeBSD repository used CVS until 2008 and changed to Subversion. Is CVS is unusable now or Subversion is much faster than CVS?

I don't know how to use Subversion and I'm familiar with Github. I wonder why FreeBSD uses Subversion although many open-source projects use Git. Is there any reason and any plan to migrate to Github?

Thanks
 
For FreeBSD checkout/commit you should use git.

More info:

Recent thread in the Forums:
Thread heads-up-freebsd-changing-from-subversion-to-git-this-weekend.78087
Thread how-to-clone-the-git-repository-from-github.75736

freebsd-git-docs on GitHub:

The FreeBSD Project on the GitHub:
https://github.com/freebsd

FreeBSD git wiki page:
https://wiki.freebsd.org/Git

FreeBSD git mailing list (freebsd-git):
http://lists.freebsd.org/mailman/listinfo/freebsd-git
freebsd-git@freebsd.org

FreeBSD Manual Pages:
git(1), git-help(1), gitcli(7), gittutorial(7), gittutorial-2(7), gitglossary(7)

Git tutorial on Warner's Random Hacking Blog (Warner Losh)
http://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html
http://bsdimp.blogspot.com/2020/10/freebsd-git-primer-for-users.html

Other related thread in the Forums:
Thread using-git-on-freebsd-why-and-how.64898
 
CVS is still very usable if you want it. It's not about being faster or not, it was about features. Here's the rational for the making the switch from CVS to Subversion for FreeBSD: https://wiki.freebsd.org/VCSWhy
Strangely, this was my experience with Subversion (and CVS)
The next problem is utterly critical. CVS's concept of branches is woefully inadequate. It has no memory of what deltas have been merged across a branch. This is no big deal for doing a branch, testing it, then doing a one-time merge into HEAD and then forgetting about it. But if you do 2 or 3 rounds of this, you're in for a whole world of hurt. Your changes will conflict with things you've already merged. Each iteration is worse than before. FreeBSD developers completely gave up on branches in cvs, except for release engineering. That's not the way it was supposed to be.
I heard that they'd added better merging support to Subversion via some Python scripts, but the one time I tried it, it was a disaster.
I wonder how much of this applies anymore
Linus: "Quite frankly, the way git works (tracking whole trees at a time, never single files), that ends up being very painful, because it's an "all or nothing" approach.

Linus: "So I'm hoping that if you guys are seriously considering git, you'd also split up the KDE repository so that it's not one single huge one, but with multiple smaller repositories (ie kdelibs might be one, and each major app would be its own)

Uhh, what? We'd have to split src/* into a mess of subtrees to make git work well?

...

Linus: "But what's probably worse, a single large repository will force everybody to always download the whole thing. That does not necessarily mean the whole *history* - git does support the notion of "shallow clones" that just download part of the history - but since git at a very fundamental level tracks the whole tree, it forces you to download the whole "width" of the tree, and you cannot say "I want just the kdelibs part".

So, if we wanted to keep our coherent tree, and use git, then you'd have to clone/branch an entire copy of /usr/src plus metadata just so you can work on a branch of src/bin/ls or src/sys. Not being able to check out src/sys is apparently a design feature. (For what its worth, I don't buy the submodules thing. There's just too much to go wrong for things getting out of sync with each other.)

We're not Linux. A good number of our best supporters stick with us because we're a coherent tree and not like linux' chaos.

Do we really like what Xorg did by splitting into hundreds of modules? That seems to be what a git strategy requires in order to work well. Linus certainly seems to be advocating that as the only "correct" way of doing things.

FWIW, my very limited experience with Subversion felt really, really slow. I'm mainly a Git user.
 
For FreeBSD development? Use what the project uses. Which is, as of a few months ago (the transition is in progress right now), git.

For development where you are a small gear in a big gearbox (like a software engineer employee in a big company)? Use whatever your manager tells you to use. If you don't like it, complain to your manager at lunchtime.

If you are in charge (like your own project, or something you are starting with a few friends, or you are a senior software engineer being asked to decide on the version control system)? That is an exceedingly complex question. The last time I had to make the decision for a whole department, I picked Perforce (the commercial version), because of the really good branching / merging implementation (our project was all about merging divergent pre-existing code streams), and because we wanted professional-strength support. The last time I had to contribute to a group decision, we ended up with git (which I supported, although it was my second choice). For my home stuff, I use Mercurial now, and for really simple things, I still use RCS.
 
Not to be too much of a Git fanboi, but I ask about the tooling whenever I'm interviewing for a new job. It would have to be a very, very enticing opportunity; and there would have to be a plan for moving to a new system before I'd ever consider working at a place that was using Subversion or CVS. I'm willing to believe Mercurial and Perforce are workable, but have unfortunately never used either in anger.

I earned the right to whine about those two systems by taking multiple turns at being merge-monkey for days (Subversion) or even weeks (CVS) at a time.
 
by taking multiple turns at being merge-monkey for days (Subversion) or even weeks (CVS) at a time.
Ugh I hated this task. A long time back at my previous job we had two fairly separate LEGO games but they shared the same custom internal "engines". Obviously my recommendation was to organise the projects so that they both depended on the single engine and just keep it up to date... but naturally the less correct solution of maintaining two separate engines came into play and a year later the manual task of merging the divergent engines fell to me.

The most annoying thing is that I did a fairly good job of the merge (I understood both flavours of the engine well because I worked on both downstream projects and knew the quirks). So the management said, "It was easy. Lets just do this again for the next 4 projects". Just another annoying thing to add to my "reasons to find another job" list ;)
 
And One more thing... what is the difference between cgit.freebsd.org and cgit-beta.freebsd.org?
 
So the management said, "It was easy. Lets just do this again for the next 4 projects". Just another annoying thing to add to my "reasons to find another job" list ;)
I've had bad management too, but it wasn't the problem in either of these cases. One was a large software project with several development teams working on feature branches and several release branches. The feature branch had to be merged to all the release branches when you were ready for testing. It was such a large project that I wasn't always sure of how to resolve conflicts in dusty corners of the code I hadn't visited yet. The procedure was a combination of bugging people and taking a wild stab at it and hoping for the best.

The other one was a small development team with a medium-sized source tree that released almost daily. Every one worked on several private feature branches and some combination of these branches would be merged into a release candidate just before being deployed to prod. The feature branches were tested independently, and the "go" for release was given by QA. One of us would become merge monkey when several private branches had to be bundled up into a larger feature branch before cutting the release candidate. There were thousands of bogus conflicts because every branch had had master merged to it several times due to the release cadence. However, there were real conflicts lurking in the sea of non-problems. It forced you to pay close attention to an incredibly boring and repetitive process for hours. The price for screwing up, or thinking that you screwed up, was to start the merge over from scratch. These were especially fun times when you added time pressure into the mix.

The first time I did a git-merge(1) and it correctly only brought up actual merge conflicts was a magical experience.
 
Back
Top