Version control

[ido]

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:

Code: [Select]

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:

Code: [Select]

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

[ido]

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.

[Krice]

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?

[Etinarg]

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.

[OrangyTang]

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

[purestrain]

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

[ido]

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.

[ido]

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.

[Slash]

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 )

[Tapio]

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.

[purestrain]

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?

[Tapio]

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.

[purestrain]

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.

[Tapio]

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

[OrangyTang]

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.