Git mirrored to SourceForge SVN

[Auntie Mangos]

Hi,

I posted a GUIDE explaining How To "Check Up" GIThub mangos directory on Windows:

http://getmangos.eu/community/viewtopic.php?id=4099

Hope this can bel helpful, greetings, Majere

[Auntie Mangos]

Git itself is no doubt superior, but it is like throwing TFS out there and telling Linux users to go find a decent tool to do pulls and commits to TFS. The tools for Windows, for git, just aren't there. They're immature and have very little integration.

http://getmangos.eu/community/showpost.php?p=45867&postcount=27

[Auntie Mangos]

I have played with Git a bit... and have read through the guides I guess the thing I'm just really having a hard time wrapping my head around is the hash build id's. Like what Dythzer mentioned here: http://getmangos.eu/community/showpost.php?p=46139&postcount=52

Maybe it's just too late at night and my head is just being a block of wood at the moment though.

[Auntie Mangos]

I have played with Git a bit... and have read through the guides I guess the thing I'm just really having a hard time wrapping my head around is the hash build id's. Like what Dythzer mentioned here: http://getmangos.eu/community/showpost.php?p=46139&postcount=52

Maybe it's just too late at night and my head is just being a block of wood at the moment though.

The id is a hash of all the files contents in the repo, it is used in place of revision numbers in svn. I'm sure that is all info you already knew. Now if you want to checkout the repo to a prior state then all you have to do is as stated run the git checkout command. However you don't have to input the whole hash just the first 8 or 9 digits. Git will figure the rest out.

git checkout adef994

That is just an example not a real commit .

Regards,

JDG

[Auntie Mangos]

You people should read more ... those forums are full of answers to "no! stay with SVN!", mine as well:

"SVN is more simple, why use GIT?" The answer is not only in bandwidth (as you can do diffs offline, etc), but in something else. Most of you lack the knowledge of what Git is able to do over SVN. Yeah, you have no damned idea what's possible with it because you can't imagine it now (still trying to compare it with SVN, eh?).

And I say it again - you have NO idea. I can promise you that if Mangos will take full advantage of what's Git possible to do, there would be no SVN mirror, just because you can't mirror all those constantly changing and temporary branches and tags (and several versions) effectively to SVN, not to mention octopus merges.

And if that happen, you won't ever want SVN back, not even the most dumb users.

http://getmangos.eu/community/viewtopic.php?id=4159

[Auntie Mangos]

@madmax76, read this http://getmangos.eu/community/showthread.php?p=46139#post46139 and the post below

[TheLuda]

Greetings,

in the light of MaNGOS development switching to Git for version control, many community members have told us that using Git would not be userfriendly or lack system integration under Windows (as there is nothing like TortoiseSVN for Git).

In the last few days I have been writing a script that will automatically import all Git commits into the Sourcefourge SVN repository. I am currently testing this with a mirror of the Git repository and a mirror of the SVN repository.

Within the next week you can expect so see this going online within the next few days if no major issues show up.

Update

The Git repository is mirrored to the Assembla.com SVN living on http://svn2.assembla.com/svn/mangos-svn-mirror/.

Commits will only go into the trunk/ and only from the master branch on GitHub. Thus development branches on GitHub will not be available on SVN.

[Niamor]

Good news

Thanks.

[rultin]

Much appreciated...I'm so glad that you are working to make this function. I think this is all that people wanted...A choice. Who knows perhaps while SVN is still available it allows some of us to play around with Git, but not rely upon it...which would ease any transition...and if enough people do this then maybe SVN will no longer be needed....

Change is fine...easing into it is much less difficult than the change being abrupt.

[floop]

I suspect there'll be whining for "when feature X that was accepted yesterday will appear in SVN?" from now on

Still it is fascinating to see how many people are afraid of learning something new

[Alex]

Thanks a lot.

floop: it's not a matter of 'learning something new'. It's more a matter of losing linear trackability of revisions. SVN offers linear revision numbers, while GIT does not. That's all.

[TheLuda]

Subversion will be there for a while, to help people get used to Git. But this mirror will not be there always. For now, I will enable this and keep it running for a few weeks until people had a chance to adapt their scripts to Git.

Just like mentioned in the GitHub announcement, Subversion will stay a while to help with transitions, but in the end SVN will die.

[jaggex]

Really nice to hear! This will "sort of" combine the best of subversion and git!

Cheers

[NetShira]

Wow thank you so much!

[floop]

I am working in a place where linear development is something of a past - there is dozens of programmers, and we all do work on code using GIT.

It's the release management task that makes the 'linear versions' out of all of those things, and it is somethign that MaNGOS admins should do.

It is how we use git:

There are three major GIT repositories. One is called "production", another is called "uat", last one is called "testing"

On "testing" there is always a version that is actually processed by.. um.. testers . UAT is done by end users.

On "production" there is always a released version.

At start, every developer does clone from current production version (some exceptions apply but rare, only when we do the parallel development of few productions at once)

1) Every task done by any developer is in his/her own branch of the repository clone

2) After finishing task, they send the confirmation that change from their repository is ready to be picked up from branch 'xyz'

3) At some point, release manager pulls data from finished tasks into test repository. The version numbering is assigned by release manager

4) When testing is finished, release manager decides which features will be pulled to the "uat" version

5) Tests are proceded again, this time on "uat" repository version

6) If they are fine, everything is pulled ito "production" repository.

It's the *release manager* task to pick up which tasks are to be combined into release, and his/hers task to assign versions. Normal developer is never able to pull data into even the testing repository.

If more than one developer should work on one feature, they can do their own repository tree structure themselves. Feel free

The key is to make all development in branches. Every separate task = separate branch, or sometimes even separate repository clone.

We work like that for quite few months, and after initial whining ('what was wrong with SVN???') nobody is trying to get back to Old Way.

Especially those who were forced to do few larger merges in SVN

So... how I'd like to see it in MaNGOS?

I would love to have similar structure, maybe not as complicated but rather:

+ "Released Version"

+-- "Next version" (nightly?)

+---- | all developers

This way the data from developers could be pulled into "Next version" repository, and when all features are tested and complete, they could be pulled into Released Version. How numbering is done, it's up to person responsible for the pulling task.

Sequential revision numbering is really a bottleneck.

[freghar]

Actually, I plan to discuss such things with TheLuda as soon as he shows up on a *certain place* (waiting for 2-3 days right now), so give it some time, ...

floop: btw .. maybe it's better to leave every developer his own repo .. as he might want to send several pull requests at the same time.

[TheLuda]

TheLuda had a free weekend without children lingering in the house. Thus my wife made use of her commit rights

[leak]

Good too see someone is taking care about the usability.

Sadly by now Tortoise >> every single GIT app for windows.

Well console is ok too but who can deny the nice patch merging and error solving support it has.

I think what is even more important than getting SVN back is the version number issue:

"Hey i run 27890e2d86134b93f15fafd206addf38a5fe0b49 what are you running?"

Well just big question mark. SHA1 might be nice for keeping the source sane but for humans it is just a pain in the ass and provides you NO information at all.

atm the .server info returns unkown version too so if you just have binaries you don't even know what is going on.

I think a linear 5 digit number (e're already at 6k with the 4 digit one) would be very nice for usability, you watch it and you get an idea what version you are running and how old it is.

Maybe apply such a number for every checkin/merge at the master branch cause that branch is linear anyways (i think?!)

I'd also use those 5 digit numbers for patches on the forums which don't have an forked mangos branch.

[Cyber]

that sound nice ^^ ty

[bogie]

afaik wyk3d is already working on a solution for that, stay tuned . however i use git-gui(mysgit?) and it works like a charm

[floop]

floop: btw .. maybe it's better to leave every developer his own repo .. as he might want to send several pull requests at the same time.

Every developer *does* need have his/hers own repo

They just should also have their own branches for all the tasks they do.

I wouldn't want to put branches on the main repos, there's no point.

[Inflames]

nice news

geez

[SneakerXZ]

Script? git-svn isn't enough? I don't understand why you have to write script.

[TheLuda]

Because it has to do this thing automatically on each commit. git-svn does it manual, and that is not what helps us.

[Morgan]

Glad to see you're going to setup a SVN repo. But it's also good to know you'll keep using GIT, I was about to get very sad since I took time to figure out GIT. I think I for one will continue just using GIT...not sense in going back now! Thanks TheLuda!