• 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
buumchakalaka

Version control for begginers

44 posts in this topic

I personally use Git for my personal projects. (C++ with DirectX) and it works fine! I have a repo through bitbucket.org Whether Git is the easiest way to go or not I'm not sure. For me it wasn't hard to setup but I've read up on how to start. (Which bitbucket has a tutorial section on how to setup a repo and your Git client) The only thing about Git and really many other version control systems is the ignore file. I didn't know what this was till recently. Pretty much the Git system has a file named ".gitignore" which you put file extensions that you don't want git to include when pushing changes. (Like special files for Visual Studio that are specific for that system in case you're going between multiple computers coding)

 

http://www.vogella.com/articles/Git/article.html < Very decent tutorial for Git. 

 

I've heard good things about Merc but never tried it personally, and same goes for SVN. 

1

Share this post


Link to post
Share on other sites
If you plan to work in a company as a developer, eventually you'll be forced to use SVN. So i'd suggest sacrificing few hours to studying SVN's.

At work we use Team Foundation Server, Microsoft crap for Microsoft related stuff.



At my hobby projects i use Java, don't want to be slave to one language. Question tho, does anybody know good and easy to set up SVN for Eclipse? Edited by Sollum
1

Share this post


Link to post
Share on other sites
+1 for Git. The nice thing about Git too is that you can keep a local repository if you don't want/can't get an online one. If you want to learn more about Git, Scott Chacon created an online version of his book, Pro Git, which is free to view. Of course if you feel like you're getting a lot out of it, you're encouraged to purchase his book to support his hard work. smile.png I also like to use Git Extensions with Visual Studio because it provides a nice little interface for handling my repos, rather than doing everything via the command line. There are a ton of other GUI's for Git out there too if you want to check out some other ones. Some of them are listed here. Good luck!

^ thanks for explaining a bit more about Git. :P I use Git Extensions all the time and its amazing compared to the normal Git Gui application.

 

 

This is almost a bit like "which language is better, C++ or Java", tell me which one to use.   :-)

 

In the end, the "correct" answer is probably use whichever has the best integration (in your file manager and/or your IDE). Everything else really doesn't matter all that much, because most revision control systems (with the exception of RCS which is a nightmare!) do more or less exactly the same thing for most people.

 

Assuming you use Windows, like most people, Subversion is probably a good choice, in particular TortoiseSVN. It doesn't cost anything, it does the job, and it comes as a double-click-to-install package that adds a context menu to Windows Explorer. It's totally foolproof. You can get free hosting on the internet everywhere, and you can run it locally on your filesystem or on your NAT. What more do you need?

 

Git is a good alternative if you need a distributed version control system (But, do you really need this? To me, this is rather a serious disadvantage, and the "one big advantage" of having the entire repo at hand is nothing that filesystem-local Subversion doesn't do, too). Git is great if you develop under Linux, it installs in 3 seconds and works without problems. Under Windows, it's a different story. I've found getting Git to work rather painful, and it didn't do anything that Subversion didn't do in the end (and contrary to common propaganda, it wasn't any faster). Git is great if you have 1500 developers. Do you have that many?

So you would suggest SVN over Git if you were a single developer / only a few working on a project? I've personally only used Git for personal applications. Where as the company I work at uses SVN / TFS for everything. It seemed like SVN would be better for a work environment. Also, (not sure of my info here just warning) if I'm not mistaken isn't SVN suppose to be setup like a server on a computer / on a server? I use Bitbucket because I'm able to code and push changes at work (on my break) and at home whenever. Where as SVN would be a server at home. (it probably would be possibly too access the info from work with some port forwarding) 

 

Just a few inquiries. :) I never see threads like this so it's great to finally see one!

2

Share this post


Link to post
Share on other sites

samoth makes a good point that you need to consider your needs before selecting the version control system that is right for you.


It's always good to learn something new, and exposure to version control software is definitely a good thing for a future career in software development, but one option open to you is to not use any version control software. From your post it seems that you are kean to focus your attention on the development of your game, so perhpas you could simply use .zip files to create snapshots of your code at key moments (e.g. every major release). This may suit your needs just fine.

2

Share this post


Link to post
Share on other sites
You don't need to setup a new server on your computer to run a local subversion repository. You can just create a database on your hard disk. It works pretty much the same as using a server but instead of doing [tt]svn co svn://blah.blah.blah/blah/blah[/tt] you use [tt]svn co file://blah/blah/blah/blah[/tt].

I personally prefer using git for single developer work even on Windows, though to be honest I don't really notice any difference in workflow between SVN and git in that situation. Since I already use cygwin, installing it is as painless as selecting the package in the cygwin installer.

 

Hmm. I suppose I was just worried about losing data honestly. Hence why I went with an online repository. I have yet to REALLY look at SVN but I've always heard it great. However, while looking up "Git VS Svn" there were a few articles about pros and cons (http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git)

2

Share this post


Link to post
Share on other sites

I wouldnt use SVN anymore. Mercurial(hg) and git are the modern things.
Mercurial is very easy to set up if you are new to version control and instead of finding out about setting up a db first for SVN, you just go into some folder, type "hg init", "hg add", "hg commit", type in your commit message and you have your source from that folder already inside a local repository. Now if you want it more complicated you could use git, which can do essentially the same as Mercurial but some things have other names.

2

Share this post


Link to post
Share on other sites

My friend introduced me to Git last year and I use it for everything. It's an amazingly powerful tool and its documentation is unbelievably complete. Particularly with a branching model like git-flow.

2

Share this post


Link to post
Share on other sites

Can any of these control software be used by someone who knows little about IT and in particular game development?  The reason I ask is that I know someone who is thinking about starting a company to make software.  Should he just leave the version control to someone else such as the lead programmer or could he use any of this software mentioned here? The company head uses windows and would need a very user friendly sv system, so what should I recommend?

1

Share this post


Link to post
Share on other sites
Can any of these control software be used by someone who knows little about IT and in particular game development?  The reason I ask is that I know someone who is thinking about starting a company to make software.  Should he just leave the version control to someone else such as the lead programmer or could he use any of this software mentioned here? The company head uses windows and would need a very user friendly sv system, so what should I recommend?

Just about all the VCSs have nice "friendly" GUIs.  The question is what features and what workflow do they want. Let the programmers pick, as it affects their day-to-day lives the most. Anyone can use VCS. There's nothing magical about it, as for binary assets it just lets you see a file history for any files commited to it.  The magic only really shows up for code centric operations on text files.  It handles several people editing the same files at the same time, and single developers wanting to edit the same file in 3 different ways (ie. new feature + 2 seperate bug fixes). In those cases VCSs provide a complicated array of capabilities to manage those edits without letting them stomp on each other.

2

Share this post


Link to post
Share on other sites
At work we use Team Foundation Server, Microsoft crap for Microsoft related stuff.

"Team Foundation" Server? Sounds quite cheesy to me. Like "The Fruits of our Labour that Hold us Togheter as a Family!" Server or something.

0

Share this post


Link to post
Share on other sites

I won't try to repeat a lot of what's been said, but some reasons I like git is that:

  • No need for a server/internet connection; you can commit, do diffs, or view the log all on your local system
  • You can push the same repository and updates to several locations (so I can push my code to my home server, where it gets backed up on the cloud; also I can push to Github or Google Code, or my school team's repo on the school computers, etc)
  • I can pull from several locations (I've got the same repositories on my Windows and OS X partitions, and when I switch OSs/partitions I can just pull updates from the local file path (OS X can't write to the Windows partition, and the Windows partition can't write to the OS X partition, which is why I have to do this and why this feature is so nice to me))

 

I don't do a ton with git; I'm no ninja when it comes to version control. However, the idea that you can push and pull updates to and from anywhere is so nice with git (and other distributed version controls systems, but I've only used git). With centralized version control systems (a la SVN), you've got one place you push and pull your updates to and from, which means I can't push/pull to/from different partitions or other computers like I can with git.

Edited by Cornstalks
1

Share this post


Link to post
Share on other sites
I won't try to repeat a lot of what's been said, but some reasons I like git is that:
  • No need for a server/internet connection; you can commit, do diffs, or view the log all on your local system
  • You can push the same repository and updates to several locations (so I can push my code to my home server, where it gets backed up on the cloud; also I can push to Github or Google Code, or my school team's repo on the school computers, etc)
  • I can pull from several locations (I've got the same repositories on my Windows and OS X partitions, and when I switch OSs/partitions I can just pull updates from the local file path (OS X can't write to the Windows partition, and the Windows partition can't write to the OS X partition, which is why I have to do this and why this feature is so nice to me))

 

I don't do a ton with git; I'm no ninja when it comes to version control. However, the idea that you can push and pull updates to and from anywhere is so nice with git (and other distributed version controls systems, but I've only used git). With centralized version control systems (a la SVN), you've got one place you push and pull your updates to and from, which means I can't push/pull to/from different partitions or other computers like I can with git.

 

That's my reasoning for using GIT honestly. I use it on my lunch at work to push and pull changes and then at home and it's great. You COULD do that with SVN but it would have to be through your router at home. 

1

Share this post


Link to post
Share on other sites

I dislike git because I find it has a really steep learning curve and it's command interface is not intuitive. I've used it a couple times in the past, but my sour experience could be biased because the project manager I was working for last made it harder to use than it should have been. I do fully acknowledge that git is more powerful than SVN and I do love the distributed nature of the system. I just haven't warmed up to it, and being told that "oh the documentation is so complete" doesn't really encourage me, since there are literally textbooks written just to explain how to use this tool. I don't want to read a textbook or sit through 2-3 hours of tutorial videos just to use a damn source control tool. I only want to know the minimal amount that I need to know to do 95-99% of the tasks that I will have to encounter day-to-day.

 

I'm interested in giving Mercurial a study, as it seems to offer most of the same primary advantages of git, but is more user friendly and easier to pick up and immediately start getting things done. My project is still using SVN for now, but eventually we'll be moving to either git or Mercurial when the time is right for us.

1

Share this post


Link to post
Share on other sites

[quote name='Roots' timestamp='1358748793' post='5023773']
I'm interested in giving Mercurial a study
[/quote]There's nothing to study in Mercurial AFAIK, it just works.

0

Share this post


Link to post
Share on other sites
These days, for professional large-scale work, a non-distributed VCS is right out. Distributed is just better.

Git is the tool with the highest potential but you can't go with it unless everyone involved is a "developer type" and tolerant of the sometimes user-hostile UI.

Mercurial offers much of the same benefits while being much friendlier; IMO it is a good default. Edited by Stroppy Katamari
2

Share this post


Link to post
Share on other sites
Git is the tool with the highest potential but you can't go with it unless everyone involved is a "developer type" and tolerant of the sometimes user-hostile UI.

 

That pretty much summarizes it for me. I acknowledge that Git is a very capable revision control system (and probably a lot more suitable than e.g. Subversion in some areas, such developing an operating system with thousands of contributors, and sending updates by email).

 

However, when I use a revision control system (or really any software), I expect it to just do the job and make my life easier. It must install in under a minute, and it must run from the IDE or from Explorer (or whatever filemanager you use), and not require me to think or do more than 2 clicks for tasks that I do 5-10 times per day.

 

Am I a developer? Yes, but I'm also a user. When I have to find an excuse for the sticks that a software throws between my legs, that's a dealbreaker for me. At least, as long as there is something else that doesn't try to bend me. I don't want to install a 200MB package (msys-git, anyone?) to have a simple thing as revision control running. I also don't want to install Cygwin for that matter (of course, if you already use Cygwin anyway, as SiCrane pointed out, it's a non-issue).

 

Insofar, one really has to weight the advantages and disadvantages individually, because our needs (and perception, and willingness to bend) are individual, too.

 

I don't need more than 5 developers (maybe one day it will be 8 or 10?), so I couldn't care less whether a DRCS works much better for 1500 developers. I'm not writing an operating system, and I don't want to send updates by email. I want to click "commit" and everyone can check them out. As long as this works, and a commit does not take longer than a few seconds, I'm fine (well, and a few more operations, obviously -- but you get the idea).

 

It's mighty fine if the repository lives on a server, no objections to that. In fact, I consider this a huge advantage. In my case, "server"  is a WD MyBookLive that regularly backs up to another WD MyBookLive,  -- that's server plus no-care backup for under 200 Euros, with a total of 15W power consumption. Requires 2 ethernet cables, 10 mins setup (most of it due to installing ipkg first and running idle3-tools, Subversion was more like... 20 seconds), zero trouble, zero maintenance.

In a few years when the drive is a bit older, another 100 Euros will buy a replacement. If my computer's harddisk dies, last week's work that I haven't yet mailed to the rest of the team won't be lost (of course, one could argue that there's the possibility of both MBLs exploding without warning the same day, but let's stay serious). So really, I don't see how this isn't a perfectly applicable solution.

 

Of course other people have different needs, so again: Decide what you need, then see what integrates best.

1

Share this post


Link to post
Share on other sites

So, broadly, there are two types of Version Control Systems VCSs): Distributed and centralized.

 

The centralized model is kind of like a library -- Everyone gets read-only copies of the files so that the software can be built, but to modify a file you first have to check it out. This is tracked by a centralized database. I think most of the modern ones will allow checkout by multiple people, but you'll have to merge any collisions that occur if two programmers modify the same file. Subversion (VCS) is the most modern centralized VCS, and is the only (free) one worth looking at if you prefer the centralized model.

 

The distributed model is very different -- Everyone has a full, writable copy of the entire project, and the encouraged workflow is to create a branch for each complete change or feature. As such, branching is a very light and fast operation is distributed VCSs (whereas its slow and heavy for centralized VCSs). However, you can also use a distributed SCM in essentially the same way as a centralized VCS if you want, except that you declare the files you modify after you modify them, rather than before -- although I do not recommend this. Git and Mercurial (Hg) are the two dominant distributed VCSs, but there are many others to choose from, like Fossil and Bazaar. Git seems to be most popular, especially with the GNU/Linux crowd, and is the VCS of choice for the Linux Kernel, but Mercurial is quite competitive, feature wise. In my experience, Mercurial is more beginner-friendly, mostly because it tries to help you not make mistakes. Git seems to take the approach of less hand-holding, but gives you more access to the guts of the system to clean up mistakes when they happen.

 

 

I'd also point out that for game development I tend to prefer keeping source-code in distributed VCSs, and game assets like textures and sounds in a centralized VCS. I just think that assets lend themselves more naturally to the library, check-out/check-in model, than code does. For example, if two artists modify the same texture at once, there's typically no good way to merge those changes, so you'd end up having to redo-the work a third time. Also, most artists aren't programmers, and distributed VCSs are fairly hostile towards non-programmers -- and its just nice to know that some well-meaning artist isn't doing to bork your entire repository by mistake; its stressful enough to worry the same over your less-experienced developers.

2

Share this post


Link to post
Share on other sites

Two important advantages that modern VCSes like git or hg have over their last-century forebears like SCCS, RCS, CVS, SVN, VSS, etc. are this.

 

(1) atomic commits -- when you commit more than one file, it's done as a unit.  It can be reverted as a unit.  Do not consider this a trivial advantage, since one of the main reasons for having a VCS is so you can revert to a known good point.  Having a VCS that does not have atomic reverts is like having a car with no wheels or axle.

 

(2) branching speed -- SVN branching is tangled and confusing at best, and impractical in a real project.  On larger professional-level projects using SVN we would have to freeze developer checkins for about 48 hours while the repo was being branched for release.  After that, changes would have to be made on both branch and trunk for a while, since the branches had diverged.  Branching with a modern VCS is instantaneous and a normal part of every day workflow:  branch, make a few changes and commit them, repeat, merge to trunk (or another branch).  Cherry picks between branches are simple and fast.

 

So, if you use VCS the way most people do backups (ie. never rely on them), or if you're a single developer working on a very small project that will never be released, yer grampa's source control is great.  For everything else, there's a DVCS.

Edited by Bregma
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