Temple of The Roguelike Forums
Development => Programming => Topic started by: Krice on June 20, 2010, 05:36:14 PM
-
So I heard that people use version control like all the time. I have never used that tool and I don't know why I should do that. Is it strange just make backup copies of the current source?
-
Yes, it is strange, because it doesn't give you the benefits of version control--which are essentially irrefutable.
Version control (usually) stores deltas of files. Changes are recorded, not entirely new files, along with a commit message--a message saying what these changes are. This lets you do a lot of things: you can trace the change of a file, you can effortlessly see the changes that might have introduced a new bug (i.e. if there's a bug in SomeObject, you can do a diff on SomeObject.cpp from revision to revision and see what's changed). It allows for much more coordinated collaboration between developers on the same project--two developers can work even on the same file, and so long as their changes don't directly override each others', any good version control system will merge your commits. If they do overlap, you'll be in a state of conflict, and you can resolve the conflicts manually and commit the fixed version in.
EDIT: For the sake of example: me and my devs have been working on Sharplike for about three weeks. We have around 270 commits from three developers. We regularly break things, and we regularly revert out to known-working versions and just keep on trucking. This vastly improves our productivity and lets us concentrate on working, instead of trying to remember what we did when we screwed something.
Basically: there's no good reason not to use version control.
-
It also helps when you work from several workstations, you can keep the source code in a central location and not worrying about "where is the latest version". You can even abandon the project and come back months later, and the latest version will still be there.
The benefits for team working are undeniable of course
-
And of course using a online repository means your code wont be lost to the ages.
-
offsite backup (assuming you push your repo away from your local machine).. tracking changes, branching, merging, rolling back.. also helps that I code on my workstation and laptop and I can checkout/build and test on multiple machines..
so yeah your and odd duck krice :P but you knew that... ;) just dont pick subversion, its crap.
-
CVS is crap. RCS is crap. Subversion is excellent at what it does.
-
Well none of those features are something I need, and using a version control seems to me like extra work for no obvious reason (for a solo developer like myself).
-
so yeah your and odd duck krice :P but you knew that... ;) just dont pick subversion, its crap.
Would agree that. Use e.g. mercurial - its very easy and distributed. You can do local commits too, no scrap .svn folders in each subdirectory.
I'm currently developing alone, too but it gives me the following benefits:
- Track changes for later changelog
- Visible progress
- Revert stupid changes
- Support multiple versions (e.g. bugfix in branch 0.6 => 0.6a, main development on trunk)
- Backups
Just use it
-
It's so easy to use that the question you need to ask yourself isn't "why should I use a VCS?" but "why shouldn't I use a VCS?".
At the very least it's easier than manually copying and zipping folders.
-
At the very least it's easier than manually copying and zipping folders.
Really? Is there a non-sucky version control I could try (probably with my new roguelike EFT).
-
I made good experiences with CVS, but that will be called horribly outdated as of now.
GIT is the latest hype I hear. Should be easy enough to set up, I guess. It's fast, safe and distributed, doesn't need a central server repository or anything like that.
-
I've heard that git is a little more involved than mercurial, but I only have experience with mercurial. That said, mercurial is dead simple to use.
-
Unless you are developing exclusively with Unix-based developers, git (it's not capitalized, by the way) is considerably inferior to Mercurial.
-
Mercurial is considerably inferior to git imo. but mostly don't care what anyone else uses.
-
Maybe you both could explain a litte bit more about the pros/cons of using mercurial/git (not any technical things how something is implemented)t? I have tried both for some weeks but found them equally good.
In the end i decided to use mercurial because of its support of multiple platforms and good integration into eclipse.
-
At the very least it's easier than manually copying and zipping folders.
Really? Is there a non-sucky version control I could try (probably with my new roguelike EFT).
I should have qualified that it's easier to use after the initial not-very-long one-time setup.
I use mercurial, which doesn't require you to connect to a server if you don't want to (but gives you the option to do it if you do).
After you install it (http://mercurial.selenic.com/ -> there are also GUI versions if you prefer that) to set it up for the first time:
hg init (project-directory)
cd (project-directory)
(add/create some files)
hg add
hg commit -m 'Initial commit'
And then every time you change/create some files and want to commit a new change-set you do:
hg add
hg commit -m 'Changed x, y, z; Fixed bugs a, b, c.'
The resulting version is the equivalent to a new zip file in your manual system.
Even the "hg add" line is only needed if you've created new files since the last commit, otherwise it's just "hg commit" (you can omit the -m flag and hg will just launch a text editor for you - when you save and quit it it will enter the text you wrote there into the commit message).
-
Maybe you both could explain a litte bit more about the pros/cons of using mercurial/git (not any technical things how something is implemented)t? I have tried both for some weeks but found them equally good.
In the end i decided to use mercurial because of its support of multiple platforms and good integration into eclipse.
I (long time CVS and then subversion (aka SVN) user) tried git first and found it a bit harder to use than subversion. Then I gave mercurial a try, liked it, and never looked back.
Neither of them is perfect but the relative similarity in interface between mercurial and subversion made it easier to use for me.
From an objective point of view I think they are probably about the same, for me mercurial (aka hg) is just subjectively easier to use.
-
At the very least it's easier than manually copying and zipping folders.
Really? Started looking at hundred page manual of CVS and when I saw linux-like command line stuff I stopped right there. Easier?
-
It depends.
When you zip your stuff, the cvs equivalent is cvs commit -m"my changes of today"
When you unzip your stuff the cvs equivalent is either cvs update or cvs checkout
It's command line, but not really that different. And there are graphical tools for CVS, although I have never used them.
The hundred other pages for CVS you'll need if you branch your project, and try to merge changes from one branch into an other. Much of the rest is also magic that most projects never need.
Edit: if you want to learn a version control system, maybe CVS is not the right one to start. It's dying, SVN is already better, and GIT and Mercurial are definitely a whole generation more advanced. If you start today, try to use one of todays systems.
-
At the very least it's easier than manually copying and zipping folders.
Really? Started looking at hundred page manual of CVS and when I saw linux-like command line stuff I stopped right there. Easier?
Firstly, don't use CVS. It's old and creaky - Subversion (SVN) was written to be a modern replacement for it, so use that instead.
If you're on windows, ditch all that command line crap and install tortoiseSVN: http://tortoisesvn.net/node/347
It puts all the svn operations on your context menu, so you just have to update / commit with a single click. Once that's installed read tortoise's help and it'll show you how to set up a repository and working copy (again, all through the context menu, no command line required).
-
Maybe you both could explain a litte bit more about the pros/cons of using mercurial/git (not any technical things how something is implemented)t? I have tried both for some weeks but found them equally good.
In the end i decided to use mercurial because of its support of multiple platforms and good integration into eclipse.
I (long time CVS and then subversion (aka SVN) user) tried git first and found it a bit harder to use than subversion. Then I gave mercurial a try, liked it, and never looked back.
Neither of them is perfect but the relative similarity in interface between mercurial and subversion made it easier to use for me.
From an objective point of view I think they are probably about the same, for me mercurial (aka hg) is just subjectively easier to use.
Then when did web-rl use svn instead of mercurial? ;) I had the same experience; i tried git because everyone talked about it but with lack of tools it was no choice.
But i'm really interested why mercurial is inferior
-
At the very least it's easier than manually copying and zipping folders.
Really? Started looking at hundred page manual of CVS and when I saw linux-like command line stuff I stopped right there. Easier?
Why on earth would you want to use CVS these days? It's decades out of date.
-
Maybe you both could explain a litte bit more about the pros/cons of using mercurial/git (not any technical things how something is implemented)t? I have tried both for some weeks but found them equally good.
In the end i decided to use mercurial because of its support of multiple platforms and good integration into eclipse.
I (long time CVS and then subversion (aka SVN) user) tried git first and found it a bit harder to use than subversion. Then I gave mercurial a try, liked it, and never looked back.
Neither of them is perfect but the relative similarity in interface between mercurial and subversion made it easier to use for me.
From an objective point of view I think they are probably about the same, for me mercurial (aka hg) is just subjectively easier to use.
Then when did web-rl use svn instead of mercurial? ;) I had the same experience; i tried git because everyone talked about it but with lack of tools it was no choice.
But i'm really interested why mercurial is inferior
That was before I switched to Mercurial (I went back to subversion after trying git). Anything from the past several months is mercurial.
-
I am thinking on using mercurial for next projects, right now SVN has been good enough for single branched projects such as mine.
I still use CVS at work though (shame on me) probably because there's been a CVS server installed at the company servers for ages and nobody wants to setup a SVN one (nobody wants to take responsability of its mantainance :P)
-
I use git and love it. However, I haven't really heard anything bad about Mercurial (they say on Windows it is better, but I haven't have any problems with git either). Historically git might have been a bit hard to learn, but those times are long gone. Git gives quite verbose output from its commands, including hints about what you might want to do next, whereas Mercurial uses e.g. svn-style status info, which is very compact. The basic commands work almost identically in both git and Mercurial. In any case, distributed version control system is the way to go (third option in that category would be Bazaar (bzr), but it is not as widely used and much slower than git and hg).
One thing fundamentally different with svn and git is that svn branches are just copies of the directory (and tags are read-only copies), whereas git (and I believe Mercurial also) repository is a "pool" of commits and branches + tags are just pointers to certain commits. This leads to smaller repo size and super-fast, very cheap branching.
Here's some things why I use VC for lone projects also:
* Branching - I can do something experimental in a separate branch (e.g. test SFML instead of SDL) and also continue work on the "stable" and then if I decide experimental stuff is good, merging them together is easy.
* Sense of going forward - commits show that I've managed to to something.
* Generate changelogs.
* Find out where a bug was introduced by using half-automated (could actually be fully) git-bisect binary search on the commits.
-
One thing fundamentally different with svn and git is that svn branches are just copies of the directory (and tags are read-only copies), whereas git (and I believe Mercurial also) repository is a "pool" of commits and branches + tags are just pointers to certain commits. This leads to smaller repo size and super-fast, very cheap branching.
You mean "super fast and cheap branching" in svn, right?
-
One thing fundamentally different with svn and git is that svn branches are just copies of the directory (and tags are read-only copies), whereas git (and I believe Mercurial also) repository is a "pool" of commits and branches + tags are just pointers to certain commits. This leads to smaller repo size and super-fast, very cheap branching.
You mean "super fast and cheap branching" in svn, right?
If you have a large project, copying the files to make a new branch in svn can take some time. Also, at the same time you double the disk space usage. Git branch is a 40-byte text file that contains the commit id of the branch's HEAD. That can be generated in negligible time (and uses effectively no additional disk space - of course additional commits to the branch start to take some, but it'll be a while until it is close to duplicating the files). Of course if you have the svn branches already checked out, switching is just changing directory, whereas git needs to patch some files.
A note though: with git, you are also free to use svn-style branches. You can have the project git-cloned multiple times and if you wish to merge stuff, just git-pull from the other repo.
-
Strange; i always thought branching was super fast (of course without checkout) since it's just some sort of hardlink to a svn-revision. Maybe i'm incorrect; i'll check it out at work.
-
Strange; i always thought branching was super fast (of course without checkout) since it's just some sort of hardlink to a svn-revision. Maybe i'm incorrect; i'll check it out at work.
Yes, svn seems to do some hard-linking in the server side, but a checkout is still needed for working on the new branch, right? And client side doesn't use linking? Anyway, maybe I gave a bad example of git's and svn's differences, since I guess it isn't the most relevant thing to newbie users.
A few things I don't like with svn is how it doesn't seem to give any indication of progress - checkouts/updates just spam the file names to the terminal without telling how much is left, whereas git clone/pull gives a nice percent count (on top of usually being much quicker) (don't know/remember what hg does) (if you know some switch to change svn's behaviour, I'm all ears). However, the main thing I like about distributed systems is the lack of network latency: I tend to e.g. check the log quite often and see diffs of old revisions and with DVCS, those are just instant whereas with svn, I got to wait - sometimes just a little, sometimes seconds - and even though that might sound small, after you've gotten used to instant, seconds feel like ages.
EDIT: Also, git-log goes straight to less/more-like scroller environment, with latest commit right on top there to see, whereas with svn I usually end up striking ctrl+c to get the horrible log spamming to stop and then I need either to scroll back the terminal to find the latest stuff or re-run, piping to less or head or whatever (this is using command-line of course).
-
One thing fundamentally different with svn and git is that svn branches are just copies of the directory (and tags are read-only copies), whereas git (and I believe Mercurial also) repository is a "pool" of commits and branches + tags are just pointers to certain commits. This leads to smaller repo size and super-fast, very cheap branching.
You mean "super fast and cheap branching" in svn, right?
If you have a large project, copying the files to make a new branch in svn can take some time. Also, at the same time you double the disk space usage.
To make a branch/tag in SVN, you do indeed 'make a copy', but you do it directly on the server with a copy command. This makes it near-instant and doesn't require any additional file space since internally it's just marked as a copy of an existing revision.
If you're making branches/tags by copying a local workspace and checking it in again, you're Doing It Wrong.