next »

[MikeD]

Hey guys,

I've used a lot of version control systems in the past, liked some, didn't like some. We've been using bitbucket with source tree for a couple months now and it works but the windows client seems slow and buggy at times. We've been looking into getting a perforce server for my small studio.

Basically, what repository/version control system do you guys use and why? Would like to just hear some thoughts and opinions.


Thanks,
Mike

[ThemsAllTook]

Command-line subversion. It does exactly what I want in a simple, easy-to-use way. Everyone is trying to get me to use git, but every experience I've had with it has been horrendously overcomplicated and painful.

[fractilegames]

Command-line subversion. It does exactly what I want in a simple, easy-to-use way. Everyone is trying to get me to use git, but every experience I've had with it has been horrendously overcomplicated and painful.

Exactly same here. Git is not bad, but it feels overly complicated for what I really need. I'll stick to subversion for now too

[Richard Kain]

I have a Linux box at my house (Ubuntu) that I keep Subversion running on. I access it with different software, depending on the platform. For my Windows boxes I usually just use Tortoise. But the back-end is vanilla SVN. I usually work alone, so it's mainly just for backing up and keeping track of my revisions.

[Eigen]

Git repository on BitBucket using SourceTree. Perfect.

[riksteri]

I'm trying different version control systems for different projects - I can't know what's best until I've tried them all!

SVN I don't like at all. Git is nice. Mercurial is "like Git but better". Perforce I've only used a little bit for now, didn't get a good first impression, but it's too early to judge. Their diff tool has been good, that's what I use for diffing and merging regardless of the VCS I'm using for the project. Next in line would be Fossil, but I'm not there yet.

This has been discussed here a lot in the past, maybe there's material there to help you.

Version control worth it for single developer?
Version control for your games
Source/Version Control?
Version Control

You might find more with the search function.

[bdsowers]

I use both Perforce and SVN (with GUI clients - Tortoise and Versions) pretty extensively. I lean toward Perforce for the larger team projects and SVN for my personal stuff.

I don't have strong arguments here. Perforce feels better for resolving differences and doing management-level tasks like branching. SVN is lightweight and lets me just throw up some files quickly without any fuss.

[Cheesegrater]

We recently switched source control systems at work. We evaluated Perforce and SVN, and went with SVN. Price was part of it, but a lot of it was that the Perforce GUI client has some odd design choices (for example, diffing between versions is accomplished by dragging one revision ID onto another in the history list, with no visual clue that you can do this).

If you're using anything that isn't perforce, and you have a large enough team that you're doing a lot of merging, do yourself a favor and look into getting Pro licenses of Beyond Compare for everybody. BC's three way merge can save you a lot of time.

[Layl]

I use git myself. It's a well known fact that the git tools for diffing and merging are sub par. You can in fact use the perforce diff tool with it but for me that never worked well. What I've been using lately it Atom's packages for working with git. Atom's sometimes a bit slow to start up but for me these work really well.

https://atom.io/packages/merge-conflicts
https://atom.io/packages/git-diff-details

[darkhog]

SourceTree? Puh-lease! You said you were on Windoze. How about TortoiseGit or TortoiseSVN (I think there's one for Mercurial as well, but not sure)? They integrate nicely into the Explorer and are so easy that even someone like me, who couldn't write valid git command for a live (except maybe git clone), can use those.

[powly]

I use git -- originally because of peer pressure. I've learned to like it though, probably not a perfect (or maybe even the best) solution, but it gets the job done.

[Cheezmeister]

I cut my teeth on SVN but gradually shifted to git. I'll never go back. The learning curve is brutal because (a) DVCS follows entirely different paradigms that are not intuitive; and (b) the commands are named stupidly and have no built-in abbreviations. HOWEVER:

Once you get critical mass with git comfort level, you can be more productive than with SVN (if you're on Windows, do yourself a favor and use TortoiseGit). Plus, GitHub is totally dope. I can't speak to Mercurial (hg) but word on the street is it's even better.

I use Perforce at work and I hate it. Its only saving graces are being reliable and scaling with enormous codebases, which may be important to some enterprises, but is certainly not for me. It's clunky, prone to bad state, has a learning curve on par with git's and it's easily to accidentally attempt to pull down the entire repo.

[nickgravelyn]

I'd toss out that Git/Mercurial are generally not well suited towards large projects with lots of binary files. I've seen Mercurial start really becoming a bottleneck around 700MB and I'd guess Git's similar. There are things like git-annex and other hacks, but they are hacks that rely on external file shares and are kind of a pain to deal with. If you are making a very content heavy game and plan to iterate on binary files a lot, you may want to consider that centralized systems tend to handle this better. Perforce is used by a lot of big industry teams for this reason, though SVN (at least from my experience) works pretty well there, too.

Basically I'd say don't pick entirely based on usability; make sure you consider the technical side as well. There's also no reason you have to use only one of them ever. I'm using Git for my current project because it's fairly light in the content department (a few sprites, a couple fonts, and our audio) but my next game will likely be more content heavy so I may go back to SVN or Perforce for that project.

Just some food for thought. 

[Layl]

I'd toss out that Git/Mercurial are generally not well suited towards large projects with lots of binary files. I've seen Mercurial start really becoming a bottleneck around 700MB and I'd guess Git's similar.

That's because Mercurial and Git aren't supposed to be used for binary files. Especially Git chokes when you make it try to make sense of that. Git expects you to use something else for keeping track of large binary files and to never ever include libraries in binary form in your project.

[MikeD]

A lot of good opinions here, I appreciate the responses.

Usability is an important factor I look into, since not a lot of people in my studio (including artists) have much experience with command-line tools. But from a technical perspective, what I am ultimately looking for is scalability. We're building a lot of reusable assets, libraries and tools along side with a medium scale game project. I think my decision is pretty clear now.

Now to my follow on question: Automation! I'm a big fan of automation and continuous integration. We're currently using Buildbot but I've been looking into Jenkins as it seems to have better support for running tests and presenting data nicely. For those of you who use CI, what tools and process do you guys use? Just curious to hear ya'll pipeline.

[Layl]

For those of you who use CI, what tools and process do you guys use? Just curious to hear ya'll pipeline.

I use appveyor, it's pretty much specific to .NET projects. It's simple to use, free for open source and has nice NuGet integration. It has streamlined my publishing process a LOT.

[DocProctopus]

I use git because I'm familiar with it from my (non-game software) job, with a combination of command line, sourcetree, and tortoisegit depending on what specific thing I'm doing with it. I really wouldn't recommend git for working with Unity, though, because it handles binary/blobs so poorly. I've honestly had better luck just sticking my Unity projects in a Dropbox folder, though I recognize that's not a solution for professionals or teams of more than maybe two.

[Layl]

I really wouldn't recommend git for working with Unity, though, because it handles binary/blobs so poorly.

You can set Unity to use a text format instead of a binary format for files. The biggest pain with Unity is finding what you're supposed to gitignore.

[InfiniteStateMachine]

My overall favorite is perforce but it has a learning & setup curve. Once you get it going it's great though. This is what I would use for a team project and considering a 20 user license is now free even better. More than 20 users I guess I would have to have a long hard think about it because it's not cheap.

When I'm working on personal projects I typically use Mercurial and host on bitbucket. Often I don't even push and just use it as a nice local backup system.

Lately I've had to become acquainted with Git  and I'm in that phase where I currently dont love it but I understand that I still don't fully understand the DCVS mindset so I'll reserve my judgement until I've used it more. I do see some things about it that indicate it could scale well for projects with hundreds of coders. Although sometimes I feel like you are merely deferring the merge pain.

Finally I started with SVN and it's a fine system. Used it for 6 years on a project where a snapshot was about 2GB and it survived through 10000+ commits with very few issues. It's a great option if you have a large team, can't afford peforce and have a nice server sitting around.

I'm interested to try out perforce git fusion sometime. The dream of having DCVS with perfoce's CL style of working sounds pretty cool. Not sure how well it would work in practice though.

We recently switched source control systems at work. We evaluated Perforce and SVN, and went with SVN. Price was part of it, but a lot of it was that the Perforce GUI client has some odd design choices (for example, diffing between versions is accomplished by dragging one revision ID onto another in the history list, with no visual clue that you can do this).

If you're using anything that isn't perforce, and you have a large enough team that you're doing a lot of merging, do yourself a favor and look into getting Pro licenses of Beyond Compare for everybody. BC's three way merge can save you a lot of time.

That doesn't sound right. I'm pretty sure there's other ways to do it. At the very least you can use the graph view with the revision time slider.

I do love Beyond Compare for 3ways although I don't love the way it maintains white space (just a taste thing, a lot of people love that about BC). So I end up using BC for 3way and Code compare for 2way. Code compare is basically a free attempted clone of Araxis Merge.

[MorleyDev]

I like Git (and let's be honest, it's currently the winner of the version control wars), but the thing you have to get your head around to really work with it compared to SVN is that "big bang commits" and "heavy branches" aren't handle well by it. Which is good, because they aren't things you should do anyway. And SVN handles them terribly as well, it's just they're also the default way of working with SVN because of it's centralised nature.

A branch should be a single feature/bug-fix/piece-of-work, and only live for a short time. See gitflow.
A commit should always be describable in a single sentence, without using the word "and".

These are the things that cause pain with SVN, because it (in my experience) encourages long-running branches and big commits, as otherwise you break the build by committing in a broken state. This means you get branches that are a pain to merge into trunk/master/develop, and commits that cause merge conflicts for your teammates who so much as look at the same file as you've edited (and vice-versa).

You can commit in a broken state with git, and you should (just don't push to source control until green). This is how git handles merges well: It plays back the changes made, one after the other, so each change needs to be as small as possible for it to do this job effectively. SVN seems to try and do merges 'after-the-fact' by figuring out the difference, which falls down a lot more often (again, in my experience).

If you and your team like this way of working (I do), git is great. If you don't, git is terrible. (And the year 2005 called, they want to know why you stole their time machine). So long as you work to those 2 guidelines (small branches and small commits), git has some of the best merge and diff tools around.

Git also doesn't handle binary files well, but ideally your build process should be pulling your binary files in from a dedicated binary repository anyway. And that binary repository can be SVN, and in fact the same things that make SVN poor for me for source code make SVN decent for binaries.

And speaking of build process, Jenkins is decent but requires you to put in some work and go plugin-hunting to make it fit your process (which it can do, there's a plugin for everything). Free ones such as travis-ci and AppVeyour are nice but limit you, so it's kinda a cost-reward calculation.