Handmade Hero » Forums » Code » Casey'a Version Control System
brcolow
Mike E
1 posts
#2998 Casey'a Version Control System
2 years, 9 months ago

Casey mentioned in the previous couple streams that he uses a custom version control system that he wrote himself. I told my friend about this and he was quite shocked. We started discussing this and we are both very curious if there are any details about this system anywhere and if not, would you provide some details about the system? E.g. what type of vcs n implementation details, reason you wrote it, etc. Thanks very much!
mmozeiko
Mārtiņš Možeiko
1518 posts
1 project
#2999 Casey'a Version Control System
2 years, 9 months ago

Casey has already mentioned why and how his VCS works. If I remember correctly his VCS simply archives files ands stores somewhere in one place and maybe few other things. He had mentioned that older version is available here:http://mollyrocket.com/729

As for why he did this, I believe same reason as every other "shocking" thing you see on his stream (build system, variable naming etc.. :) In this case because his VCS tool is simple, does everything he needs and other VCS software is terrible and too complex (to what I partially agree).
cmuratori
Casey Muratori
803 posts
1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#3011 Casey'a Version Control System
2 years, 9 months ago

Yeah - basically I think version control should be essentially invisible. But that is the opposite of how most version control systems work. Modern version control systems require _four commands_ at a minimum just to do a day's work (pull, merge, commit, push) _if_ nothing goes wrong. This is absurd and makes no sense. People like to claim it makes sense by going on these long tangents that make it pretty clear they are only able to think about the problem in the context of the VCS they use. But if you take a step back, you realize that version control has become essentially the opposite of what it should be: it wastes your time rather than saving you time.

I have not written a good VCS yet - the one I wrote it just good for what I do and is not meant for use in teams. But it would definitely be nice to someday apply the same principles to a larger-scale VCS so there could be one that doesn't waste everyone's time!

- Casey
benwaffle
Ben
7 posts
#3012 Casey'a Version Control System
2 years, 9 months ago

You don't need to pull or merge unless others are working on your code. cmirror seems to do the equivalent of commit and push
5sw
Sven
33 posts
#3018 Casey'a Version Control System
2 years, 9 months ago

cmuratori
Modern version control systems require _four commands_ at a minimum just to do a day's work (pull, merge, commit, push) _if_ nothing goes wrong. This is absurd and makes no sense.


Have you ever used a modern VCS? This claim is absurd and makes no sense. Here is why. (I will use Git as an example here, because that's what I know and use)

Yes, most VCS systems have those four operations and that is because they are absolutely required when sharing a central repository between multiple developers. But for a single developer usually 'commit' is the only thing actually required.

Pull/Push is there to get your changes to and from a server. Can't work together with other developers without that. But since you are working alone you don't need them, Git is perfectly happy to have a single developer work within a single local repository.

Merge is basically the whole point of version control - it's used to bring code you and your teammates write together. Git is really good at this, so you just enter your merge command and you have your merge results. Try merging some non-trivial amount of code without the help of a VCS. But since you are working alone and not doing any branching you can forget about merge - you don't need it.

So that leaves the "commit" command. I bet your own VCS has this too. Without a commit operation there is no version control.
mmozeiko
Mārtiņš Možeiko
1518 posts
1 project
#3019 Casey'a Version Control System
2 years, 9 months ago Edited by Mārtiņš Možeiko on March 15, 2015, 11:38 a.m.

Any reasonable developer will set up his local repository to be pushed/pulled to somewhere else other that his local dev machine (be it github, local NAS or something else). Otherwise what will happen if you'll accidentally run "rm -rf folder_where_is_your_repo" or your SSD gets corrupted or laptop gets stolen? So push/pull is a must have.
5sw
Sven
33 posts
#3021 Casey'a Version Control System
2 years, 9 months ago

mmozeiko
Any reasonable developer will set up his local repository to be pushed/pulled to somewhere else other that his local dev machine (be it github, local NAS or something else). Otherwise what will happen if you'll accidentally run "rm -rf folder_where_is_your_repo" or your SSD gets corrupted or laptop gets stolen? So push/pull is a must have.


Only if you use your VCS also as a backup. This is certainly better than no backups at all but not the smartest to do.
cmuratori
Casey Muratori
803 posts
1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#3023 Casey'a Version Control System
2 years, 9 months ago

Yes, I have used modern version control. I have used Git lightly, but Mercurial more extensively, and Perforce and SVN regularly.

I don't appreciate the assumption that the reason I think something is bad is because I don't use it, so this discussion is over.

- Casey
Pseudonym
Andrew Bromage
174 posts
1 project
(tbd)
#3046 Casey'a Version Control System
2 years, 9 months ago

cmuratori
Yeah - basically I think version control should be essentially invisible.

That would be ideal, but I suspect that it's not possible in large teams, distributed teams, mission-critical systems, safety-critical systems, or any kind of project where serious money from an external source who demands regular milestones is on the line.

As soon as you have mandatory code reviews, or multiple supported releases, or any of those other necessary evils, version control is inherently no longer invisible. Hell, it's supposed to get in the way of you just pushing changes.

And speaking of code reviews...

5cw
Merge is basically the whole point of version control - it's used to bring code you and your teammates write together. Git is really good at this, so you just enter your merge command and you have your merge results.

Clearly you've never used Gerrit! It's possible that things have changed recently, but last time I checked, Gerrit doesn't support merge commits. You must rebase your changes, and rebasing is by far the most error-prone operation in Git. Not to blow my own horn, but I have the reputation around the office as the person who can unbork a repository after a broken rebase. So definitely use Git; it means more job security for me.

To be fair to Gerrit, there's a damn good reason for this: Merging means that the same changes must be reviewed multiple times, whereas rebasing forces the edit history to be linear. It's a pain, but once again, giving up some convenience is the price you pay for working in that space.

Don't get me wrong: I do like Git's internal model, and it's by far the least worst VCS that I've ever used. The interface does leave a lot to be desired, though.

The only programs that I like and have no issues with are the ones that do one thing and do it well. I really like the GNU linker, for example. It stays out of the way right up until the point where you need to do something complex, and at that point, it lets you do it.

Anything else, and in particular anything which has to do a complex job, I have problems with. If you don't have problems with your tools, then you might not be using them with a critical eye. And the best criticisms of a piece of software almost always come from those who use it regularly, because they know from bitter experience where the real issues lie.

sub f{($f)[email protected]_;print"$f(q{$f});";}f(q{sub f{($f)[email protected]_;print"$f(q{$f});";}f});
C0D3
popcorn
71 posts

#3048 Casey'a Version Control System
2 years, 9 months ago

I know this is over but I would just like to say......

svn..is the most utter crap version control I have ever used. Using it makes me want to punch a hole in the wall.

"The important thing is not to stop questioning. Curiosity has its own reason for existing. One can't help but be in awe when he contemplates the mysteries of structure of reality. Never lose a holy curiosity." -Albert Einstein
miotatsu
岩倉 澪
115 posts
1 project

riscy.tv host

#3051 Casey'a Version Control System
2 years, 9 months ago

SVN is good (relatively speaking) as a poor mans version control of binary resources (art and music assets, etc). Correct me if I'm wrong, but I believe this is one of the selling points for Perforce towards the game industry as well.

I'm using git for my projects source code, but once I have some art/music/etc assets in the mix, I'm planning on keeping a seperate repo for them using svn.
Mephisztoe
Christian Jacob
11 posts
#3228 Casey'a Version Control System
2 years, 8 months ago

This is not intended to start another round of discussion, but only a question: Besides the release of the source of Cmirror itself (consisting of approx. 4.000 LOC that I _could_ read and examine to understand the tool as a last resort): Does any "manual" exist or some sort of read.me that explains the usage of Cmirror?

Cheers,
mephisztoe
cmuratori
Casey Muratori
803 posts
1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#3231 Casey'a Version Control System
2 years, 8 months ago

I'm not sure. I don't think so? Basically you just type "cmirror", that's it - there's no commands or anything. But there is a cmirror.config file that you use to say where the server is, which files to ignore, etc., and that's the part that could use some documentation, since there's a bunch of nice features there that you might want to use (and some that you "have" to use, like saying where the server is).

- Casey
Mephisztoe
Christian Jacob
11 posts
#3235 Casey'a Version Control System
2 years, 8 months ago

The thing is, I don't actually know what "that" is, that cmirror does (without studying its code). I already extracted a list of config keys and built a config file that probably has the correct list of possible settings. Next step would be finding out the syntax of the values so that cmirror is able to import them. And then I need to find out how cmirror works so that I actually know which settings I "have" to use and what they do and which settings I don't neccessarily have to use (but could,.. so what those are for would be a nice thing to know as well) :)
cmuratori
Casey Muratori
803 posts
1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#3260 Casey'a Version Control System
2 years, 8 months ago

Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
// This is central/local repository
Central = "some/path/to/server/directory";
CentralCache = "some/path/to/server/cache.file";
Local = "some/path/to/local/directory";

// Source files get stamped
PreCheckin = "*.cpp;*.c;*.h;*.inl;*.txt;*.mm;*.shader;*.vs;*.ps" "ckeyword" "";
SyncPrintThreshold = 1024;

// These are files which are generated, so I don't care about conflicts
IgnoreConflicts = "bin/*";
SuppressIgnores = true;
SummarizeIgnores = true;

// These are files I don't want to ever have added
Ignore = "recycler";
Ignore = "recycled";
Ignore = "$recycle.bin";
Ignore = "*/.~lock.*";


The typical use case is that you make 3 directories. One is for "working", and that is just your dev directory that you work in. You don't specify this anywhere. The second one is your "local" directory, which is where cmirror keeps the most recent files, unedited. And the third is the "central" directory on the server where you want to keep the versioned backups.

You put the cmirror.config at the root of your working directory. Then anywhere in that directory, when you want to update, you just type "cmirror".

That's it.

I apologize if this config is not 100% correct, I'm on a much later version myself than the last publicly posted one, so I tried to edit it down to the original syntax but may have forgotten some things.

- Casey