SRL Archive - General

Why git is cool


Markus

2010-03-08 15:48:33

[admin]
RM:
This is a thread that is up in devs + ssrl + simba forums
I'm copying it here cus I find it extremely interesting and think you might as well.
I'd also like to hear what your opinions on git are.
[/admin]

[admin]This same thread is also available at
http://villavu.com/forum/showthread.php?t=55481
http://villavu.com/forum/showthread.php?t=55619
http://villavu.com/forum/showthread.php?t=55620
The fact that it's pain to merge the actual replies between these threads clearly shows why svn sucks for branching[/admin]

Before you read this entirely, you think: "Bleh, git sucks, it's different than svn thus it's bad and it sucks and it's to hard to use for me" <— that kind of stuff
After reading this, you only have one question left: "Why didn't you tell me that like three years ago or so, when SRL was actually useful for macroing?".

So I'll ask you to read this completely, as I was convinced by git's power, and you know I'm really sceptical when it comes down to new stuff ;) So yea, just read this and make up your own opinion. We're going to use git anyways, but this way it seems like a democratic choice xD jkz

Git can do anything SubVersioN can, but better/faster/more efficient/1337er
What's the usual workflow when you're going to develop on SRL? It's like this (slightly exaggerated but you get the point)

  1. You checkout the latest revision
  2. You edit the files
  3. You become angry because there are lots of merging conflicts between the trunk and the stuff you're working on right now
  4. After you resolved the issues and you devved some of your own stuff, you commit
It may seem efficient (everybody sees your changes and stuff), but it's actually baaad if you're like working on some antirandom, because you can't just commit it and leave people with only a 50% functioning SRL. That just won't work.

So what would you do using git instead? You would create a branch!

Of course you know what a branch is in the usual term (tree branch, you know the thing with all the leaves attached), and it's quite similar in terms of source code management:
(I'll quote Wikipedia):

Branching, in revision control and software configuration management, is the duplication of an object under revision control (such as a source code file, or a directory tree) so that modifications can happen in parallel along both branches.


In plain English: you duplicate your source, so you can work parallel on it. So you basically have 2 SRL's, the "stable" one, and the one with your incomplete antirandom.
You continue happily working on your antirandom, not influenced by any work of anyone else, so you can do it in peace. In the main branch you continue updating/fixing bugs and stuff, the regular work.

Right now, that doesn't differ too much from subversion you might think, but there are two fundamental differences:

  1. Branching is really really really easy to do (git branch newantirandom creates the branch, git checkout master switches back to the master branch).
  2. The main branch (if you can speak of a main branch, more of that later), is also a branch. That also means that your antirandom branch behaves exactly the same as the regular branch. There are no differences in usage between them.
I'll explain my last point a bit more in the next part:

With git, there are NO central repositories, everything is distributed
OH HELP I DONT KNOW WHAT THE FUCK I SHOULD DO LIKE THERE'S NOT A SINGLE SRL AND IT'S ALL ANARCHY ARRGHHHHHHH!!!!!

^ the first thing you think when reading this (if you actually understand what I mean with distribution ofc)

However, this is easy to explain. Git can work works well with a network of trust. I made a nice pic with some examples :)


This pic shows quite a few things used in git, but first I'll explain some stuff:


  • Wizzup, Ray, Nielsie and Nava fully trust each other. They are all working on the main branch of SRL, the one which Wizzup puts up at regular intervals as a tarball at the Simba update server.
  • That they fully trust each other means that Wizzup? will happily pull from their repos. Pulling is: Wizzup will apply all changes that Nielsie/Ray/Nava made to his own branch. Pushing is the opposite, it's like that Ray shoves his changes up Wizzup's throat :p (it's like checkout/commit in svn terms)
  • What if a conflict occurs between for example Nielsie's awesome new TPA algorithm, and Ray's leet stuff which used the old one? Well then Wizzup just goes like "Ray and Niels, fixx it", Ray and Niels work things out and Wizzup is happy again :)
  • Markus, Sumilion and Zyt3x are working on a new antirandom. They are pulling and pushing happily from eachother, and the leetest Maze solver ever starts to form shape. When it's ready,I merge the branch back with the mainline, I submit it to Ray as I probably made some nub mistake. Ray will send it to Nava for speed increase x2, Nava sends it to Niels for final bugchecking and he pushes it to Wizzup. Wizzup likes it and releases a new SRL -> everybody's happy.
  • However, some bugs are found in SRL! The new Maze solver doesn't click "Click to Continue" despite all the testing Niels/Nava/Ray did. However, some jrs. noticed this immediately. They fix it, and contact Coh3n, who checks it out. He thinks the fixes are fine and pushes them to Nava, as Wizzup doesn't trust Coh3n fullly. After that Wizzup releases a new SRL -> SRL is fixed yet again, and almost no dev intervention required :p Good for our productivity,
  • As it's the same as above, I'll leave EC! and Naum out for now, but basically the line is a bit more direct (Nava trusts them a bit, so the lchain of trust is smaller).

As you can read above: both branching and distributed development are really really really useful in terms of Runescape cheating. The forums will actually be used for talk about the development itself ('I made good st00f, please pull from me!"), and no more code-clutter. I can just post "hey, pull rev 123341232131bcasd from me as your function DoSomeWeirdStuff had some bugs", and it's fine!

Some other advantages is that we can pick devs on actual ability instead of activity. Their stuff will eventually end up at Wizzup anyways, and if he trusts them enough he can add a straight line :).

Some other properties of git is that it's way faster than subversion, and just as easy to use (see the stuff I explained above about branching and stuff? I only used git for 10 minutes and figured it out. I never did *anything* with git before ;)).

One thing I haven't talked a lot about yet is branch merging: basically, when I created the mazesolver, once we think it's ready we merge it back with the regular SRL. This means that the branch with the mazesolver will be gone, and the solvercode will be merged with the main branch (including all the history!). That's really cool of course, you can create, merge, trash branches as you see fit, and all of this really easy! No sweat, just a few commands :) This in contrary to subversion where branching is a pain and all of the branches pop up in the public repos thus disturbing others.
So after you're done with the antirandom, you go just like git merch newantirandoms. To the command-line paranoid people: this *should* be doable with the git GUI (cheeatah) but it seems to be a bit bugged at my pc or w/ever.

tl;dr

  • It's faster
  • It's just as easy
  • It allows EVERYONE to dev on SRL without fucking up the public repos ("You always got some morons who try to destroy your source code. I can choose to trust only the few people who i think are trustworthy, and they make changes for me". - Linus Torvalds)
  • Thus it allows for better/more community involvement,
Thanks for reading, and we're switching to git regardless of your opinion (which should be quite positive after reading this anyways) x)

Got any questions? Feel free to post. We'll try to answer them as clearly as possible!
Any other comments are also welcome as usual.

Coh3n

2010-03-11 23:42:37

From: Markus

Of course you know what a branch is in the usual term (tree branch, you know the thing with all the leaves attached), and it's quite similar in terms of source code management:

Lol'd.

Looks good to me and if everyone can commit it'll allow for quicker updates when the Devs aren't available, which decreases bitching from the people who don't like the read. :)

Sir R. M8gic1an

2010-03-14 07:57:46

I just read this for the second time, and I've got a question.

Say there's a straight line between me and nava (full trust). If I push my changes, will Nava automatically get them, or will he have to pull them?

~RM

Wizzup?

2010-03-14 08:00:35

From: Rasta Magician
I just read this for the second time, and I've got a question.

Say there's a straight line between me and nava (full trust). If I push my changes, will Nava automatically get them, or will he have to pull them?

~RM


Usually you can assume that you don't have direct access to each others repos. So he'll have to pull them.

Markus

2010-03-14 08:10:18

You shouldn't really think of those straight lines (full trust) as in something you configure in git, but more something that you adhere to.

Sir R. M8gic1an

2010-03-14 08:23:19

From: Wizzup?
Usually you can assume that you don't have direct access to each others repos. So he'll have to pull them.


:) I was hoping for that.

~RM

Sir R. M8gic1an

2010-03-14 08:27:55

I deleted a few posts after having copyed the thread. This is just a copy of the main thread.

MSI, waht are your views, opinions and ideas about git?

(git = possible replacement of svn)

~RM

Nava2

2010-03-14 09:18:10

LOL @ the second warning. This post is great though :)

Coh3n

2010-03-14 11:49:57

From: Rasta Magician
I deleted a few posts after having copyed the thread. This is just a copy of the main thread.

MSI, waht are your views, opinions and ideas about git?

(git = possible replacement of svn)

~RM

Well I haven't used it yet, but from what I've read it seems like it would be better. I think we should stick with SVN for now. I think we need to get this released before making any drastic changes.

Nava2

2010-03-14 12:43:41

git isn't a drastic change. Just saying.

It means you type 'git pull' rather than 'svn up'. I'm obviously exhaggerating, but it's not a big deal.

Sir R. M8gic1an

2010-03-14 12:48:05

From: Nava2
git isn't a drastic change. Just saying.

It means you type 'git pull' rather than 'svn up'. I'm obviously exhaggerating, but it's not a big deal.


I suspect most of us will just simly be using the gui ;)

~RM

Coh3n

2010-03-14 12:56:05

From: Nava2
git isn't a drastic change. Just saying.

It means you type 'git pull' rather than 'svn up'. I'm obviously exhaggerating, but it's not a big deal.

I don't know. It may be better to use git when we release. It doesn't really matter to me either way.

Sir R. M8gic1an

2010-03-14 13:04:20

From: Coh3n
I don't know. It may be better to use git when we release. It doesn't really matter to me either way.


I don't think we should even consider using git before the first release. Let it be released, no need for any inside changes just yet. After the first release we can then consider switching over to git.

~RM

Coh3n

2010-03-14 13:06:53

From: Rasta Magician
I don't think we should even consider using git before the first release. Let it be released, no need for any inside changes just yet. After the first release we can then consider switching over to git.

~RM

Works for me. :)

Nava2

2010-03-14 14:40:23

I think it would make sense to switch before release then people who try to use svn they all of a sudden have to switch. Plus since simba and srl are going git, why shouldn't the srl standard MSI project follow? :p

Sir R. M8gic1an

2010-03-14 14:48:00

From: Nava2
I think it would make sense to switch before release then people who try to use svn they all of a sudden have to switch. Plus since simba and srl are going git, why shouldn't the srl standard MSI project follow? :p


It will follow. But if we change now, it'll take longer to release. Rather release sooner, change to git later.

~RM

Wizzup?

2010-03-14 14:54:00

I agree with delaying the switch. Let's first see how SRL5 and Simba go with git.