In 2020, people tend to use Git to store configuration or TODO files. That makes no sense. I started a VCS comparison with the special focus on overhead for managing one single file. Currently in: Git, Mercurial, Darcs and SCCS. Maybe I'll add more later.

Enjoy, I guess.

That's really fascinating.
So basically, I assume it's a waste of resources to use git to manage less than 30 files (to do the ratio with metadata files you got), and probably not the right tool for the job.

Then what would be the best version control system to manage change to almost static configuration files? SCCS? I'm not so familiar with what exists in this space.

Quote:it's a waste of resources to use git to manage less than 30 files (to do the ratio with metadata files you got)

Well, Git seems to scale (in a limited way). I just tested that: 21 checked in files (1..10, a..k) make 47 files in total. It seems that there are always (at least) 26 additional files. Some of them are ".sample" files, demonstrating how to do hooks, perfect for a manual or something. Git adds them to each new repository anyway. Looks like a failed QA if you ask me.

(03-04-2020, 10:50 AM)venam Wrote: and probably not the right tool for the job.

Yup.

(03-04-2020, 10:50 AM)venam Wrote: Then what would be the best version control system to manage change to almost static configuration files? SCCS?

It depends on whether you prefer a distributed or a local approach. SCCS fills the niche of "one person versioning their own configuration" very well, but collaboration is hard(er) with it*. If you prefer collaborating efforts, Darcs might be an interesting alternative here as it is basically a cherry-picking cathedral VCS.

I haven't tried Subversion for this test, but I would assume that it cannot show its strength outside a project scope either. Also, it requires at least some kind of an "upstream server".


----------

* At least for the time being. SCCS "version 6" is gradually receiving project support and a distributed mode, but it is not quite there yet.

This reminds me a little of the "less ties" thread. The reason I use git to track small projects isn't to do with the efficiency of git, but with its ubiquity. Granted, it doesn't come into play often, and maybe we should be doing more to try and stop this semi-monopolisation of tools, but I know that I'm most likely going to be able to clone any git repo from my server onto any other developer's, or developer-oriented, system.

This is more important to me than how many metadata files the program creates.

Of course, if you want to track a developer's work, it might be a good idea to use the tools required to grab the code. Still, sometimes there are files which you don't need (or want) to share with as many people as possible.

It's always good to have a choice.

So it seems that availability of git is a strong argument. I also like the (unpacked) storage format though naming files by their hash.

Git status is also very very efficient (maybe it uses tricks with mtime), and git push/pull of large repos plays nice with bandwidth, such as the way to compare remote with local status (just compare a single hash for master for instance).

These few facts might quickly lead one to think "yeah, git's the best all of the time". Thanks for proving it false, nothing beats go checking the facts for building an opinion.

You’re welcome. :)