[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.
Version control for begginers
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.
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.
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.
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.
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.
Two important advantages [...] over their last-century forebears like SCCS, RCS, CVS, SVN, VSS, etc. are this.(1) No advantage. Why? Because contrary to Git propaganda, all commits in Subversion are atomic. A commit in Subversion succeeds or fails. There is no in-between.
(1) atomic commits
(2) branching speed
(2) Not relevant. Why? Because contrary to Git propaganda, branching in Subversion is very fast.
Do note that most of this propaganda was written by someone who openly admitted that he never even looked at Subversion based on a sentence containing the word "RCS" that he picked up somewhere and didn't understand properly. And, his fanboys.
These claims are simply untrue.
EDIT: Note that for example the GCC project uses Subversion. If branching or working with hundreds of developers was really that forbidding, then honestly I wonder how they're doing it.
Do not make the mistake of using GIT as your first source control.
I use it at work, it's very powerful, but it takes a long time to understand.
If you have a small project (~5 people) , there is no need for distributed source control. It just complicates everything.
I can make the following recommendations:
1. Use SVN
2. Use it from a GUI ( you'll understand stuff way faster then command line )
If you're using windows: Download Tortoise SVN and create a local repository.
If you want to upgrade to a server-client setup: Download Visual SVN server,.
Use GIT once you are working on giant project with several remote work - sites (e.g. Compiling a Linux Kernel) .
Using it for a small project is just looking to complicate things. Also, many SVN concepts can serve as an intro to GIT (commit,checkout,branch,merge, diff,patch, etc...) .
[quote name='Robot Ninja' timestamp='1358708069' post='5023574']
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
[/quote]
[quote name='Cornstalks' timestamp='1358727696' post='5023692']
No need for a server/internet connection; you can commit, do diffs, or view the log all on your local system
[/quote]
As mentioned before, you can use Subversion on your computer without having to install a server. Especially with TortoiseSVN it is a matter of less than 10 clicks.
[quote name='Cornstalks' timestamp='1358727696' post='5023692']
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.
[/quote]
Why not setup your own server and do all your source control on it? I found it quite easy to do.
I already had a server in a data center (for email, ftp, http, ... so adding version control was only logical) and it is not very expensive (something like 34€/45$ /month), besides you do get a much better connection than you can get with your home broadband.
[quote name='wintertime' timestamp='1358714283' post='5023612']
wouldnt use SVN anymore. Mercurial(hg) and git are the modern things.
[/quote]
Could you elaborate what features you do require that subversion doesn't support?
Scala is more modern than C, still I wouldn't force my worst enemy to only code in Scala. Well, maybe...
One more question, do you use some explorer integration? I haven't found one that is comparable with TortoiseSVN which was always a bit of a show stopper. Maybe you can recommend one (for Windows).
[quote name='3Ddreamer' timestamp='1358716783' post='5023626']
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?
[/quote]
I'm using Subversion (TortoiseSVN) myself and recommended it to my sister to keep a history of her LaTeX documents. She's a nurse and no computer nerd. She does get along well for her own stuff, since she couldn't convice any of her colleagues to use it there are hardly any conflicts to resolve.
However I believe if someone is able to handle his own documents, organizing them in directories, it should be no problem to learn to use SVN even in a more complicated environment. Note: If he/she is having trouble creating/moving/editing/deleting files and folders or if he/she is unable or unwilling to read a manual it's probabably not a good Idea to use make him/her use any version control system.
If you mean with "Should he just leave the version control to someone else such as the lead programmer" that the lead programmer should set it up and maintain it, I would say it depends. Many programmers are able to do it, however programmers aren't administrators. There is no guarantee that the programmer is able to do it. Besides maybe the programmer is not willing to do it (he became a programmer not a server admin for a reason). And then there is the cost factor, maybe a sysadmin is cheaper than a developer, then the developer shouldn't be doing it. And ne more important thing, don't give this responsibility to your lead, he has already much to do, give it to a specialized tool guy/the sysadmin/someone else, make sure he has enough time so he can still do his usual tasks.
Actually using the version control system is a task for everyone that is working with the version controlled files. If you put you source code in, all developers need to use it. If you put your assets in, all artist and designers need to use it. In addition some other people might need it, project managers, qa, ... All of those people have to be tought using the system. Don't assume that every developer you hire has already worked with your system. Make sure they really understand what does what, else they will create a mess and you will waste time cleaning up after them.
No need for a server/internet connection; you can commit, do diffs, or view the log all on your local system
As mentioned before, you can use Subversion on your computer without having to install a server. Especially with TortoiseSVN it is a matter of less than 10 clicks.
Sure, but my point was that I can have both a server that I push to and still do all that I need to without an internet connection. Maybe "no need for a server" wasn't the best way to say it and I should've just stuck with "no need for an internet connection."
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.
Why not setup your own server and do all your source control on it? I found it quite easy to do.
I did, but sometimes my internet dies or I'm programming in various places and don't have an internet connection. The lack of internet connection limits me in no way from my development though (at least from the SCM perspective). It's particularly nice when working on different partitions with no internet connection.
Simply learn both SVN and Git. I'd highly recommend learning SVN first, due to Git's steep learning curve. SVN will give you a decent understanding of VCSs in general quickly, after which you can hop into more advanced topics. I personally first hated Git when I tried to learn (and am still learning...) it after SVN, but once I got some sort of hold of it, I realized there's no going back (to SVN). As your focus is in making games, you probably end up using SVN more, assuming you will work with not-so-tech-savvy people (artists etc.). If you can, use TortoiseSVN and TortoiseGit - they'll make your life a lot easier.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
