Which are good modern version control systems (VCS)?

Version control system (VCS) is a method of tracking and distributing file changes over a computer and network. Tags: https://forums.freebsd.org/tags/vcs/

VCS use on FreeBSD
until 2006, from BSDCan 2006 https://pdfs.semanticscholar.org/ffe4/f04baa628c8eca4897b3f345ce3cb8cba96b.pdf
I remember using perhaps cms to update my source code or ports tree when I came back to using a previous version of FreeBSD, and the way of updating this had changed. It worked over plaintext. I can't find information on this anymore. CMS may have been for Content Management System.

VCS use for Ports
History of VCS in FreeBSD ports

FreeBSD 6, 7 and other versions have used net/cvsup, previously from ports, which used the programming language Modula-3 lang/modula3. https://docs-archive.freebsd.org/doc/7.4-RELEASE/usr/share/doc/handbook/cvsup.html

Later, net/csup was available in ports, then in base, which allows the same protocol to be used without needing Modula-3.

subversion was used in later releases. net/svnup was one option.

net/portsnap has been used in ports and in base alongside csup and subversion. portsnap is now in ports.

Now, git is used for ports, while portsnap is still an option in ports. There's still net/gitup available. The full git takes a bit of learning. There may have been an opensource book on it. The full git takes a lot of learning to do simple commands, and to recover the files and condition to a previous state.

Modern and practical VCS?
Question on which are good modern and practical open source version control systems (VCS)? Git, Mercurial, Fossil SCM, CVSNT, Monotone, Apache SVN?
Others
  • cvs - has limitations: no rename support, no handling permissions, primative access control
  • Puppet
  • Ansible
  • Perforce - proprietary, but allowed free uses w/ open source
  • Bazaar
  • Monotone
 
What are your requirements? One developer, dozens, tens of thousands? How big is your repository? Do you need to store binaries in the repository? Do you need security and access control? Is it going to be used within a single closed environment (like one software group within one company), or by the public? Does it have to be distributed, or are you going to run with a central server? How much merging and branching are you going to do? Does it have to be integrated into other project management tools (like build systems, code review systems)?

These days, I run mercurial for all my hobby projects. I used to like Perforce a lot, but that was 20 and 15 years ago. I strongly dislike git. The worst one I ever had to use was Rational's ClearCase.
 
I like to second ralphbsz's post:
What's 'old', 'new', or formerly or currently used on FreeBSD ain't enough to say what could be useful - 'good or worse'.
Also there cannot be drawn a line clearly, since depending on the software those neither cannot be used for version control of software source code, only, nor some are meant to, only, but for managing whole filesystem's contents.

As ralphbsz also pointed out: It's also crucial, if you're using it within collaboration, or just for your own personal use, only. For the latter one everybody shall decide for what suits her or him best, and not primarily what's used by most.

Personally I use SVN. When I started on using VCS my evaluation came to the final decision between git and SVN. I found git way too complex and complicated, even bloated for my personal needs, and SVN more comprehandable, more easy to learn on the version control job for my needs. So I decided for SVN.
Today my evaluation and decision may have another outcome, but I'm using SVN for so long time, it does all I need, I'm not going to change to another VCS until I have to.
When joining a collaboration project one have to use what they use, of course, which for app. ~98% is git.

However,
the original reason for my post comes from a complete other background.
Besides all error correction, criticism, proposals for improvement, nitpicking, and even beancounting, anyway
such listings are very valuable!
sidetone,
I like to encourage you to keep up those work, you started on a few months(?) ago!
I want you to know I appreciate and applaude that very much. 👍🤝
Producing collections - 'catalogues' - for which tasks what software there is especially, but not only for newcomers to FreeBSD, and unixlike and open source at all are very valuable!
To me it's kind of a successor/update of Unix Power Tools
To me there is no question of the value to have such.
While I don't actually know your final target, and I agree this forums is a good start to have not only published it cheap and easy, but above all to get feedback, error correction, and more input by an experienced community, I just want to ask you to consider if posts/threads in a forum only are the perfect place to publish those, or if your effort is going to perish when there is no other source where those are all collected:
like a website/blog, maybe a wiki, maybe even part of FreeBSD's wiki, or a sideshow for the official documentation, or even someday a real printed book...?
 
What are your requirements?
Hobby, small projects, even big projects.
These days, I run mercurial for all my hobby projects.
I wanted to know how Mercurial scaled up to Git, even for big projects. It relies on Python, which is ok. That depends on embedded use.
I believe that's closed source, but allowed for open source. That's not too bad though.
I found git way too complex and complicated, even bloated for my personal needs, and SVN more comprehend-able, more easy to learn on the version control job for my needs. So I decided for SVN.
I wondered what's better than git for any project even a large project. In git, I wanted to do few processes, not learn all of that which I didn't need for basic tasks. Then, read the book, and not know how to describe what I'm looking for which I'm trying to do, then have to ask someone by describing it.

Producing collections - 'catalogues' - for which tasks what software there is especially, but not only for newcomers to FreeBSD, and unixlike and open source at all are very valuable!
It seems that posting helps advance open source, especially FreeBSD and other BSD's.

While I don't actually know your final target, and I agree this forums is a good start to have not only published it cheap and easy, but above all to get feedback, error correction, and more input by a experienced community, I just want to ask you to consider if posts/threads in a forum only are the perfect place to publish those, or if your effort is going to perish when there is no other source where those are all collected:
like a website/blog, maybe a wiki, maybe even part of FreeBSD's wiki, or a sideshow for the official documentation, or even someday a real printed book...?
It's easier to post here. A wiki would be better, as others can collaborate. Also updating them, with the date I used to contribute to wikis. Some of it is for reference that anyone can use. Some software related posts are offtopic, but link to FreeBSD, because of ports, or that it can be used on FreeBSD. I believe that the information here isn't lost, unless the forums go down. Someone else can learn from it, and rehash it. I don't mind if this gets rehashed. Lists and tables can't be copyright, so that information can be reused more easily. If really needed, I could rewrite a lot. The information here, is for others plus for myself to use. I used to write howtos/faqs on here from years ago. Recently, I had an outburst of ideas to write down. Sometimes, I want to advance XMPP, other open standards, window managers or see how the community of BSD is doing or spaced apart in the world.

On this one, I asked, rather than spend more time doing research to make a faq/how-to. Plus others would contribute valuable information, which I wouldn't come up with.

I used to contribute at freebsdwiki.net. I might contribute at one of those BSD forums which has a wiki. I intended to post a few things, which I was interested in, then slow down. I kept on writing new threads as I thought of another itch.

I have a future plan for operating systems, which I can't do soon. Would make funding from that. I don't mind giving what I wrote here away. And don't always know if I can match it again. Don't always want to.
 
I use a few different VC's for different purposes.

For single files, as the lowest common denominator I use RCS. Works great with Emacs auto-save hooks to keep versions of single files forever. I use this with simple scripts and Orgmode files. This also works great for system configuration files. Nothing better than "find /etc /usr/local/etc -name '*,v'" to see what I have customized.

For small projects with up to 10 people, I prefer to use Fossil. It's centralized version control instead of distributed parallel branches, making it easier for new users to understand. It also includes ticketing, documentation, a basic web UI, and more in the base product. Git requires extra services like Github in order to do the same. Unfortunately the Windows interface for Fossil is lacking.

I also use Mercurial, as I find the CLI to be much smoother than Git. I also have a higher confidence in the technical merits of Mercurial, especially when concerning Git's ability to rewrite history. I often default to Mercurial when I have a local project that is multiple files where RCS isn't suitable, and where I'm not working with others.

I know Git is popular. However the CLI sucks so everyone has to use an interface. It's highly optimized for the Linux kernel maintainers, but most people don't need the majority of the features it has regarding distributed version control. I object to it requiring external freemium big-tech services like Github to use. You'll find a huge bandwagon effect in play around Git, when it's often a poor choice for smaller projects.
 
How does devel/pijul compare to Git and Mercurial for DVCS (Distributed Version Control System)? Aside from Pijul having lots of dependencies, and being in Rust. Pijul uses math for comparison and revision control.

It seems like Fossil would be beneficial for wikis, so multiple people can edit a page section at once.
 
You defiantly do not need github to use git. I use a headless git server on my network (github is secondary if at all for me; I use it for public access to hobby projects.

Git is chalked full of stuff you don't typically need but that isn't saying you have to use it (all VSCs have stuff you don't really need). I think some people may be trying to use a VCS incorrectly (especially for a hobby project with single digit members); all you need basically is: `add`, `commit`, `log`, `status`, `push` and `pull`. -i.e. you don't need `branch` if you're working alone, for example, because if you want a branch to test out some crazy idea, cd to another directory and do a `clone ...` and start testing. If the idea fails, backup a directory and do an `rm -f ...`. If the idea passes do a `push`.

Instead of trying to conform to some book's--or project's--definition of a workflow, focus on your commit standards; this will allow you to use a VSC for what it's intended for (going back if things go wobbly).

Here is a `brief` on my git server (note: the 'alternate methods' listed in the below are a bit more hygienic versions of mine but should work well).

I personally use git but I really want to like fossil (not a big fan of the wiki, forum, etc. in fossil though. I can see how they'd be nice some time but more of a distraction I'd suspect).
 
About Fossil:
Could you please elaborate on that?
I thought I saw that on one of those comparison sites. I'm not sure whether it meant if security was needed that: fossil was over plain text, which often doesn't matter for VCS, or it had to do with data integrity. I possibly misread it. Tried looking for it, but couldn't find it again. I'll cross it out. If information about it comes up, it can be re-discussed.

Fossil SCM is interesting that the same creator of it, D. Richard Hipp, also created Sqlite. It seemed that Fossil used Sqlite as a dependency, but I don't see this dependency chain on FreeBSD. Hipp used Fossil to aid in Sqlite development. Fossil-scm uses a BSD license. https://fossil-scm.org/home/doc/trunk/www/index.wiki, devel/fossil & databases/sqlite3

NetBSD has used Fossil before: https://blog.netbsd.org/tnf/entry/new_home_for_the_repository.

NetBSD & Pkgsrc use cvs: https://www.netbsd.org/docs/pkgsrc/submit.html. Recent & past discussions of which modern VCS NetBSD should use:

Mozilla, W3C, OpenJDK and PyPy have used Mercurial. Apache, SourceForge have used Apache's SVN. This is the same SVN which FreeBSD has used. https://www.infoworld.com/article/2...rnatives-fossil-mercurial-and-subversion.html. Some of these projects or organizations no longer use some of these VCS.


Version control category in the FreeBSD wiki: https://wiki.freebsd.org/VersionControl
 
I mean, even good-old-CVS is sufficient for NetBSD and OpenBSD. In fact, even an OpenBSD developer stated that CVS is good enough for them and there is no reason to switch: https://cvs.afresh1.com/~andrew/o/why-cvs.html

I think that FreeBSD's switch to git was rather pointless. What problem did it solve? No-one seems to be able to give an answer. Also, it was basically an encouragement of GPLed code. SVN was under the ALv2. Git is under 'GPLv2
 
I mean, even good-old-CVS is sufficient for NetBSD and OpenBSD. In fact, even an OpenBSD developer stated that CVS is good enough for them and there is no reason to switch: https://cvs.afresh1.com/~andrew/o/why-cvs.html

I think that FreeBSD's switch to git was rather pointless. What problem did it solve? No-one seems to be able to give an answer. Also, it was basically an encouragement of GPLed code. SVN was under the ALv2. Git is under 'GPLv2
Git benefits mostly developers. Comparing it to CVS & Subversion is silly as it's in a different league.

On systems without ZFS I tend to track /etc with git: `cd /etc ; sudo git init . ; sudo chmod 700 .git ; sudo git add . ; sudo git commit -m init`

And then you can track any changes with `git diff` & `git status`.

NetBSD is also using git so maybe you should migrate to OpenBSD that sticks with slow CVS.
 
just a quick link of how a Linux kernel developer can try out proposed patches. I found this glorious.
everything is still based on git, but the supporting scripts automate a lot of faffing about.

tl;dr​

  • Use b4 to apply random patches locally for patch review. (b4 is a python-based script that works on top of git and automates a few chores that a developer needs to do when pushing/pulling patches on the mailinglists.)
  • Use lei to pull down emails and patches you care about for all linux kernel mailinglists locally. (think procmail, but instead of processing emails it can apply filters that target a specific driver, time intervals, etc on lore.kernel.org's web API)
  • Use mutt to read that email and respond. (optional, one can use any MUA)
  • Use msmtp for sending email using your email server’s settings. (optional, one can use a web API to push out patches)
 
So much drama. I would imagine Git adoption was/is for (more) developer collaboration opportunities (-i.e. pull requests). Sure, patch works good but...

If you don't want GPL: non developer: `gitup` developer: `got` or `fossil`.

Don't forget 'got' has code which you can use too.
 
just wondering, these AI morons are not worried that the code they steal could be complete junk?
I mean netscape was abandoned for a reason. I heard bind's code smells as well. not to mention possible feedback loops happening in github copiloted code
 
Back
Top