• Create Account

Banner advertising on our site currently available from just $5! # Version control for begginers Old topic! Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic. 49 replies to this topic ### #21Krohm Crossbones+ - Reputation: 3660 Like 0Likes Like Posted 21 January 2013 - 01:34 AM I'm interested in giving Mercurial a study There's nothing to study in Mercurial AFAIK, it just works. Sponsor: ### #22Yrjö P. Crossbones+ - Reputation: 1416 Like 2Likes Like Posted 21 January 2013 - 09:01 AM 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, 21 January 2013 - 09:01 AM. ### #23samoth Crossbones+ - Reputation: 5662 Like 1Likes Like Posted 21 January 2013 - 11:12 AM 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. ### #24Ravyne GDNet+ - Reputation: 10437 Like 2Likes Like Posted 21 January 2013 - 11:50 AM 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. throw table_exception("(ノ ゜Д゜)ノ ︵ ┻━┻"); ### #25Bregma Crossbones+ - Reputation: 5930 Like 0Likes Like Posted 21 January 2013 - 01:20 PM 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, 21 January 2013 - 01:20 PM. Stephen M. Webb Professional Free Software Developer ### #26samoth Crossbones+ - Reputation: 5662 Like 3Likes Like Posted 21 January 2013 - 01:34 PM Two important advantages [...] over their last-century forebears like SCCS, RCS, CVS, SVN, VSS, etc. are this. (1) atomic commits (2) branching speed (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. (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. Edited by samoth, 21 January 2013 - 01:42 PM. ### #27SillyCow Members - Reputation: 927 Like 1Likes Like Posted 21 January 2013 - 03:02 PM 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...) . My browser game: Vitrage - A game of stained glass My android games : Enemies of the Crown & Killer Bees ### #28shadowomf Members - Reputation: 323 Like 1Likes Like Posted 21 January 2013 - 03:35 PM 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 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. 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 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.

wouldnt use SVN anymore. Mercurial(hg) and git are the modern things.

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).

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?

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.

### #29Cornstalks  Crossbones+   -  Reputation: 6999

Like
1Likes
Like

Posted 21 January 2013 - 04:29 PM

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.

Edited by Cornstalks, 21 January 2013 - 04:33 PM.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

### #30Stinkfist  Members   -  Reputation: 497

Like
2Likes
Like

Posted 21 January 2013 - 05:32 PM

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.

Edited by Stinkfist, 21 January 2013 - 05:39 PM.

### #31Barzai  GDNet+   -  Reputation: 668

Like
0Likes
Like

Posted 21 January 2013 - 09:01 PM

I'm curious to what extent these version control systems apply to very new developers/programmers, like me.  I'm in the very early stages of my 3rd game project (a space invaders clone) and I've decided to plan and control my process a bit more than I did in the first 2 projects.  I have a list of modules I'll need, I pick a set to put into the next revision, and then copy the last revision and give it a new rev number.  All of the coding is done from the same location, a flash drive I carry with me.

On the one hand, version control software is clearly widely used, so getting a good handle on it would be wise.  This thread demonstrates that, as does browsing jobs on craigslist.  Folks there often request links to work you've done, or a link to your git.  So, when the time comes to look for programming jobs in a couple of years, it would be good to be able to show that I'm familiar with version control.

On the other hand, there's quite a lot of other stuff that beginners also need to be learning.  If we try to add everything we need to learn in at once we'll get way too bogged down with getting a handle on new interfaces to ever learn and code anything.  Also, when I research version control most of the features they talk about are designed to make things work better for projects with multiple people modifying the code base.

Do these version control software set-ups offer more for projects with a single programmer that would make them more useful for a beginner to learn sooner rather than later?  As it stands I plan to see how my simple revision rolling method works for this project, and then hopefully move into one of the more formalized version control programs for the next project, which will be my first somewhat original game.  If SVN or git or one of the others simplify more of the process, though, it would be worthwhile to go ahead and learn it now.  Do the features available for solo programmers justify the learning curve needed?

### #32Cornstalks  Crossbones+   -  Reputation: 6999

Like
2Likes
Like

Posted 21 January 2013 - 09:09 PM

Do these version control software set-ups offer more for projects with a single programmer that would make them more useful for a beginner to learn sooner rather than later?

I would say yes. You don't have to become a version control ninja (just the basics should be good enough at first), but simply checking in your code as you develop will allow you to rewind if you totally f*** things up and need to undo a series of changes you made because you realize it's just not working this way. Beginners do that a lot

But even if you don't need to rewind back to a previous state, I think it has the added benefits that a) you get to learn a tool that you'll use for the rest of your life (even if you change between git/SVN/etc. the idea of SCM stays the same), and b) it forces you to stop and think "is this something I really want to check in?" It's a kind of self-sanity check. Sometimes I've written a quick, terrible hack, and then when I went to check in my code I had to stop and think about whether or not I felt okay checking such horrible code, and decided to write a proper fix and check that in. In other words, it can help breed good habits.

You won't die if you don't use it. You don't need to spend a lot of time on it. But it's got a few benefits.

Edited by Cornstalks, 21 January 2013 - 09:18 PM.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

### #33Barzai  GDNet+   -  Reputation: 668

Like
0Likes
Like

Posted 21 January 2013 - 09:18 PM

Do these version control software set-ups offer more for projects with a single programmer that would make them more useful for a beginner to learn sooner rather than later?

I would say yes. You don't have to become a version control ninja (just the basics should be good enough at first), but simply checking in your code as you develop will allow you to rewind if you totally f*** things up and need to undo a series of changes you made because you realize it's just not working this way. Beginners do that a lot

Hehe, good point.  I wouldn't necessarily need to master the whole thing, just get a handle on the basic stuff.  And I can attest that being able to rewind would be nice, because I f*** things up plenty.

### #34LorenzoGatti  Crossbones+   -  Reputation: 3064

Like
1Likes
Like

Posted 22 January 2013 - 03:20 AM

Two important advantages [...] over their last-century forebears like SCCS, RCS, CVS, SVN, VSS, etc. are this.

(1) atomic commits
(2) branching speed
(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.

(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.

Since when wholesale copying of an entire source tree from trunk to a branch, which is how Subversion implements branching, has become "very fast"? Maybe you are working on toy-size projects.

Subversion atomic commits either succeed or leave your local metadata corrupted. Not a good deal; Git is more robust.

Apart from these low level details, Subversion has deep issues, for example being able to take arbitrary revisions and branches as a reference for each file. When you update, you need to be aware of all stuck files, or the message that all your working copy is up to date becomes a dangerous lie.

Omae Wa Mou Shindeiru

### #35Bregma  Crossbones+   -  Reputation: 5930

Like
0Likes
Like

Posted 22 January 2013 - 08:48 AM

Two important advantages [...] over their last-century forebears like SCCS, RCS, CVS, SVN, VSS, etc. are this.

(1) atomic commits
(2) branching speed

(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.

No, svn commits are not atomic. I can commit a set of changes to git/hg/bzr/darcs as one single atomic operation, and then uncommit/revert in one single atomic operation, or cherry-pick and apply in one single atomic operation. If I'm using svn and commit a changeset of say 20 files, then I get 20 single commit operations. If I want to revert, I can perform 20 separate reversion operations. Cherry-picks aren't really possible, although I could theoretically check out two trees using the appropriate RIDs, use a modern diff tool to generate a patchset, then apply it manually and commit.

It is definitely an advantage to be able to use your source control to do merges and recovery.
(2) Not relevant. Why? Because contrary to Git propaganda, branching in Subversion is very fast.
Contrary to unsupported assertions, branching in svn is painfully slow. Like I said, we would freeze our codebase for up to 48 hours while branching took place. The freeze is necessary because of the non-atomic nature of SVN: if a developer checks in a change during the lengthy branch process you can end up with an out-of-synch branch. Of course, this was profession production software with many hundreds of thousands to lines of code, maybe millions, and thousands of source files. If you have a toy project or a small hobby project that's never going to get released, this may not be a consideration for you.
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.
I back up my claims with experience. I used SCCS when it came out, I used its successor RCS when it became available. I used CVS for years and quickly switched to SVN when it became stable enough. I've also used VSS, Perforce, and a few other commercial VCSes. I've used git for Linux kernel maintenance (hardly a trivial project) as well as many other projects. I use bzr every day for major professional projects.

I make my assertions based on observed, experienced facts. Nothing else. SVN does not have atomic commits. Branching in SVN is several orders of magnitude slower than git.
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.
I'm a GCC maintainer. It uses SVN. Branching is rare because it's very slow. Merges from development branches are slow and tedious because SVN does not support atomic commits or cherry-picking. Many developers use the git-svn front end to overcome these problems.
Stephen M. Webb
Professional Free Software Developer

### #36wintertime  Crossbones+   -  Reputation: 2574

Like
0Likes
Like

Posted 22 January 2013 - 10:05 AM

Could you elaborate what features you do require that subversion doesn't support?

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).

I'm using TortoiseHG which is very easy to install and use, though I have the habit of often just typing in the commands in the commandline because they are so easy. SVN always needs to connect to the server, you just have the last version locally. For SVN I just have a command line tool installed and only use it when I need to.

With a DVCS you always have a copy of the whole history on your computer, can easily make as many repositories as you like so you are less likely to need to cram everything into one huge repository, clone them very fast for experimenting, commit or revert or update to any version locally even without internet connection and only push to the server when you are sure its ready, easily push on your USB-stick or really anything for backup or taking it with you.

### #37samoth  Crossbones+   -  Reputation: 5662

Like
3Likes
Like

Posted 22 January 2013 - 11:33 AM

No, svn commits are not atomic. I can commit a set of changes to git/hg/bzr/darcs as one single atomic operation, and then uncommit/revert in one single atomic operation, or cherry-pick and apply in one single atomic operation. If I'm using svn and commit a changeset of say 20 files, then I get 20 single commit operations.
I don't get you. If you commit 20 files, Subversion first looks whether any of the 20 files was committed by anyone else in the mean time. If that's not the case, the commit will succeed, atomically, for all 20 files.

If any single file has been touched by anyone else in the mean time, the commit fails with "out of date, please update". A properly configured client will run the update automatically, too. Now changes are merged automatically to your working copy, if possible, or you are prompted to resolve conflicts. After resolving conflicts, you commit a second time. And, again, this will succeed (for all 20 files) or fail.

Of course you can commit 20 files one-by-one. No, that won't be atomic, what a surprise. But it won't be atomic in any other revision control software, either.

Same is true for branching. Yes, branching is (logically, not technically) a copy of a complete directory, so what? It has no bearing, there is no such thing as a half-copy. Branching "copies" all data to a new directory, but in reality it only creates a virtual directory referencing the files of the current revision. Concurrent commits to trunk (or to whatever) add new versions (with a higher revision number) to the original directory, which has absolutely no bearing for the copy.

Besides, this is the exact same way Git works internally. Torvalds only called things "tree object" and "blob object" rather than "file" and "directory", but they're still the exact same things working in the same way.
If you have a toy project or a small hobby project that's never going to get released, this may not be a consideration for you.
One of the toy projects that's never going to released and that I'm involved with had 40k downloads last week. It has slightly over 7400 files (including some non-source files) with 1.1 million lines of text/code. Doing a complete, pristine checkout takes 1m35s (tried just now). Too slow for you? OK, fair enough.

But that isn't the fault of Subversion, it's reality. This project's repo is served via WebDAV/SSL (which is pretty much Subversion's slowest possible mode of operation) on a MuchoCheapo-class server located on a different continent. Downloading lots of stuff over the internet takes time. So what, nothing surprising there. Git can't do the job any faster or better (and if someone says it does, he's either comparing apples and oranges, or just lying).

Checking out a slightly smaller (about 15%) toy project that I'm involved with, from the above mentioned server on the LAN takes 16-17 seconds. Again, not surprising, because that's close to the peak bandwidth that the NAS delivers. Downloading a .tar file of comparable size is maybe a second or two faster, not more.

Branching either of these toy projects takes about 1-2 seconds, plus the time to check out the new branch (though that time is close to zero, if you switch rather than checking out anew). So, what exactly are you trying to tell me? Your harddisk is faster than the internet? Wow, I'm shocked.

You really have to compare apples and apples, not apples and oranges. Is "branching" very fast with Git? Of course, but only because you are not branching when you're telling that you are. The act of branching involves making a copy and communicating changes to others. Half of that process is "forgotten" in the comparison.

Now of course, merging is another story. Merging usually takes days, literally. However, that's just what happens when people edit both branches without discipline. There are conflicts, and conflicts must be merged or resolved. When they cannot be merged automatically, a human has to do them by hand. That's just what it is, nothing surprising again, and Git can't do "magic" in that case either.

On the other hand, we have for example images tagged with svn:needs-lock, which is a form of "magic" that Subversion will trivially do for you, and that Git can't do at all.

To avoid a misunderstanding: Again, I'm not saying that Git is an inferior revision control system. I'm not opposing to Git as such. If you want to use it (either because of political reasons, or because you have a very special need and it really does just what you need), that's fine with me.

I'm only opposing to the Torvalds-style "Git is God's Gift to Humanity, everything else is shit" propaganda. Everything else is not shit.

Every system has its advantages and disadvantages, but they all have their legitimate place, and they all (well, almost all... my experience with RCS was truly traumatizing) work reasonably well for most people.

Edited by samoth, 22 January 2013 - 12:59 PM.

### #383Ddreamer  Crossbones+   -  Reputation: 3283

Like
0Likes
Like

Posted 24 January 2013 - 10:41 PM

In a nutshell, what are the best open source version control programs?

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

by Clinton, 3Ddreamer

### #39Cornstalks  Crossbones+   -  Reputation: 6999

Like
0Likes
Like

Posted 24 January 2013 - 11:13 PM

In a nutshell, what are the best open source version control programs?

I'd say the biggest are SVN (for central) and git or hg* (for distributed). They're at least the most common/popular. Asking for what the "best" is is a loaded question, as they're tools that have similar functionality but are fine tuned for different needs or use cases.

*The main reason I prefer git over hg is because a) git is easier/simpler/faster to say (than "hg" or hg's proper name) and b) I'm not sure how to spell hg's proper name so I never use it, hence I'm awkwardly saying "hg's proper name"

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

### #40Servant of the Lord  Crossbones+   -  Reputation: 24073

Like
0Likes
Like

Posted 25 January 2013 - 12:05 AM

Are the latest files in Mercurial's local repositories saved in their original file format or a special format / archive? What about SVN? What about git?

If I wanted to manually modify the up-to-date repository without invoking any version control tool or command, which ones permit me to do so?

I've installed multiple different source control tools before (and apparently still have TortoiseSVN and TortoiseCVS installed), but they puked over my projects' neatly organized folders with special files and junk, so I always returned to ye ol' manual zipping up the entire directory and renaming it to the current date, then TeraCopying it to other networked machines for safety. I really want, and recognize the need, to learn at least one of the major source control systems, but haven't had the time to learn and customize them to keep my project mine and not theirs.

As an analogy, I also don't like iTunes and Windows Media, for how they take over and 'organize' your music files for you - and spend alot of time crawling my computer looking for new files without being prompted to. So I organize my own music files in their folders how I choose, and I use a media player that works with me instead of takes control away from me. (I use foobar2000, if anyone was wondering)

What source control system works best with a lazy finicky micro-managing NIH nitpicking solo-programmer who-wants-files-local-and-unobfuscated like myself?

Edited by Servant of the Lord, 25 January 2013 - 12:29 PM.

It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames -

[Need web hosting? I personally like A Small Orange]

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS