Jump to content

Git mirrored to SourceForge SVN


Recommended Posts

  • Replies 126
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 38 years later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use