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



## fel1x (Dec 21, 2020)

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


----------



## a6h (Dec 21, 2020)

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:








						GitHub - bsdimp/freebsd-git-docs: Draft copies of the FreeBSD git transition documents
					

Draft copies of the FreeBSD git transition documents - GitHub - bsdimp/freebsd-git-docs: Draft copies of the FreeBSD git transition documents




					github.com
				




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


----------



## SirDice (Dec 21, 2020)

mintchoco said:


> Is CVS is unusable now or Subversion is much faster than CVS?


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


----------



## Jose (Dec 21, 2020)

SirDice said:


> 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)
> 
> ...








						How to handle big repositories with Git | Atlassian Git Tutorial
					

Learn about the major reasons behind Git repositories becoming too large and techniques to manage these repositories, from submodules to Git LFS.




					www.atlassian.com
				




FWIW, my very limited experience with Subversion felt really, really slow. I'm mainly a Git user.


----------



## ralphbsz (Dec 21, 2020)

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.


----------



## Jose (Dec 21, 2020)

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.


----------



## fel1x (Dec 26, 2020)

Ok. So when git transfer will be finished and when the current subversion repository will be closed?

PS: I posted bugs about this forum page(perforce repository) but nobody seems to work with it. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252010
Can someone fix this?


----------



## kpedersen (Dec 26, 2020)

Jose said:


> 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


----------



## fel1x (Dec 29, 2020)

And One more thing... what is the difference between cgit.freebsd.org and cgit-beta.freebsd.org?


----------



## drhowarddrfine (Dec 29, 2020)

It's in the URI.


----------



## Jose (Dec 29, 2020)

kpedersen said:


> 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.


----------

