• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ChaosEngine

Source control - branching strategies

11 posts in this topic

I'm looking into changing source control providers at work. Currently we're using a source safe style exclusive locking system with all the problems that incurs. It hasn't been a big deal up to this point but the lack of good branching is really starting to bite us.

Does anyone have any good recommendations for modern best practice with branching strategies (i.e. branch by purpose, is trunk stable, etc)?

Would appreciate any good articles or thoughts.
1

Share this post


Link to post
Share on other sites
Agreed.

Also, your branching strategy will depend heavily on what version control provider you use. For instance, with Mercurial or a similar DVCS, you can split and merge branches so easily and automatically that it just makes sense for everyone to branch exactly what they need to modify and then merge back into main trunk. Perforce is nice if you have a lot of binary data to hold, but doesn't branch as cleanly. SVN and its ilk are probably among the worst for branch flexibility.
2

Share this post


Link to post
Share on other sites
Thanks guys... that's pretty much along the lines of what I'd been thinking. As for provider, that's up for decision as well.

Was leaning towards git, but also considering mercurial.

Some questions for anyone who's used them: how well do they handle merging C# projects? What about Visual Studio integration (is that even worth it)?
0

Share this post


Link to post
Share on other sites
I would argue that Visual Studio integration is vital, but that's perhaps my bias. I know git has a plug-in that is pretty solid, though no personal experience. TFS is still solidly king in the C# bizdev world. (though perhaps less solid than ~2 years ago) Edited by Telastyn
0

Share this post


Link to post
Share on other sites

I've used SVN and Git, and I find Git is really nice for creating and switching branches whenever I would need it (not all too often). I still prefer SVN to Git though, just less complex and less work.

0

Share this post


Link to post
Share on other sites

[...] Mercurial or a similar DVCS, you can split and merge branches so easily and automatically

(Slightly off-topic) This is an argument I see popping up regularly when people discuss source control, and I never quite get it. Is this actually the case? I daresay no.

 

Branching is simple in every version control system that I've seen except RCS (which is a nightmare doing any kind of operation, not just this one). The process may be a second or two faster or slower on one or the other system, but it's a single command (or click if you have GUI integration). I couldn't imagine how it could be any simpler.

 

Merging on the other hand is easy and automatic in every version control system I know if there are no conflicts. If there are conflicts, merging requires human interaction, which may be easy or may cause the merger to throw his monitor out of the window.

 

Inhowfar does the version control system being distributed make the process of manually reviewing lines in source files (that have interdependencies in the worst case) easier?

 

0

Share this post


Link to post
Share on other sites

I don't know about Visual Studio ... but if you want to take a closer look at Git make sure the integration offers a nice way to work with the index.
SmartGit is worth the cost ... but not integrated with the IDE of course.

Most of the other tools/integrations I know are confusing and if you switch from a simple solution it is pretty dangerous to learn by doing (especially with those tools). There is quite a learning curve.
Maybe it offers easier branching ... but you need to figure out workflows that work for you.

Make sure you have enough time to get used to it - if possible appoint one person as the Git specialist who really looks into the ins and outs of Git.
Where I worked many people agreed that there needs to be a certain complexity to justify choosing Git over SVN and even CVS. It doesn't just make your life easier.

0

Share this post


Link to post
Share on other sites

[...] Mercurial or a similar DVCS, you can split and merge branches so easily and automatically

(Slightly off-topic) This is an argument I see popping up regularly when people discuss source control, and I never quite get it. Is this actually the case? I daresay no.

...

Merging on the other hand is easy and automatic in every version control system I know if there are no conflicts. If there are conflicts, merging requires human interaction, which may be easy or may cause the merger to throw his monitor out of the window.

 

Inhowfar does the version control system being distributed make the process of manually reviewing lines in source files (that have interdependencies in the worst case) easier?

Wrong question. The difference is that a smarter VCS doing a merge can handle automatically a ton of situations in which a dumber VCS will force you to manually review stuff. In theory, "distributed" doesn't make a VCS smart at merging, but in practice the design decisions necessary for one seem to be necessary for the other.

 

I'm now working with some non-technical folks on a small project. There is no way I could push Git on them, and frankly Git's usability is so awful I never got fully used to it myself. So we're going with Mercurial, picking it up as we go. Looking good so far.

0

Share this post


Link to post
Share on other sites

I used something similar before hand but my house mate showed me a technique he found called git-flow. It's amazingly helpful and I now use it for all my projects.

 

It's really just an idea but it's got a tool that apparently is being considered for merging into the mainline of Git.

0

Share this post


Link to post
Share on other sites

Well, since the idea is apparently to move away from exclusive locking, ClearCase is clearly out. Also for a million other reasons that could make me rant for hours. After a few years of CC as work, people can't wait to migrate to just about anything that isn't a user-hating excuse to sell expensive trainings. Any tool that lets you remove a view without even warning you about remaining checkouts (after which only admin intervention will allow anybody to continue working) is clearly aimed at securing the jobs of CC admins.

 

Another thing that turned out to be extremely annoying is Visual Studio integration. Accidentally type in a file -> reserved checkout "behind your back". Point is: too much (or too automated) integration isn't always a good thing.

 

We're going to move to git for now, using the same strategy as described by Telastyn. Dev branches for everyone, task branches if appropriate, releases are branched off of main and closed/locked/killed after a release. No working on main other than merging changes back to it. Though I got a feeling nobody will stick to that for small one-line fixes, especially since with git you might already consider your local repository as kind of a temporary branch (except if your machine dies, your changes are lost and you will push changes instead of actually merging).

0

Share this post


Link to post
Share on other sites
Dev branches for everyone, task branches if appropriate, releases are branched off of main and closed/locked/killed after a release. No working on main other than merging changes back to it. Though I got a feeling nobody will stick to that for small one-line fixes, especially since with git you might already consider your local repository as kind of a temporary branch (except if your machine dies, your changes are lost and you will push changes instead of actually merging).

You've basically just described git-flow. Tag your branches with prefixes so people know what is expected on that branch. Make use of 'hotfix/branch-name' for fixes that need to be done then have them merged to master. Edited by BinaryPhysics
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0