GIT Rev number?

[ae3265]

One of the big issues with SVN and SourceForge was the increasing instability. The SVN repository was over 1.4GB in size with full history.

Additionaly SVN does not work offline, Git does. You have full diffs and logs even without internet connection. That all is stuff SVN does not have.

Plus, many people constantly downloaded from SVN, where it was not necessary.

Git is intended for developers, and it is used to ease development process.

For "normal" users who just want to run MaNGOS, there will be pre-built binaries once the switch to client 3.0.2 is done.

While the revision thing is currently a bit of a nuisance, overall I'm very impressed with the speed of git, and considering the various headaches with the previous location of Mangos, I'm glad to see the Dev's taking some action to try to address the issues.

A question on pre-built binaries, however, and we may want to fork this over to a new thread...

One of the reasons I've been compiling my own is that for various reasons, other folks' binaries haven't worked on my system. Usually this seems to be related to linking MySQL libs, but it's been easier for me to compile. I do find that kind of strange, as I'm using Macports MySQL installation, so it's nothing that out of the ordinary.

Considering the nature of this issue, how do the devs envision dealing with this sort of thing on the Mac/Unix/Linux platform? Personally, if they work "out of the box", I'd love to have a good, stable, frequently updated set of bins.

Also, on that note, what are the thoughts on rolling in the mangos4mac patches (both the base and posix threading patches) from the m4m folks?

Finally, as a Mac/Unix guy, I did notice in the past that frequently Unix builds have been broken by changes in code. Do you guys have sufficient resources in the various OS's to cut down on this in the future? If not, what can I do to help? I'm not a programmer, I'm more of a Unix sysadmin, but I'd be more than happy to do what I can to help ease the pain of Mac/Unix builds.

Again, thanks to the devs, and folks, stop bitchng and whining. Git isn't that hard to figure out, it's just a bit different. This is a learning project, so get off yer duff's and learn how to deal with git.

My $0.02 worth!

[TheLuda]

And for who are you developing then?

MaNGOS was and is intended to be a thing for developers. In its' current state, it is not for normal users like Jon and Jane Doe. Unless you see an official announcement, we still consider this to be pre-release software.

I'll wait for an alternative revnumber and I bet so is the mayority of the MaNGOS community, but I don't know where you get this arrogance somtimes, you treat some community members several times. It's not about the change to GIT it's the missing rev numbers here and nothing else.

There is no difference in revision numbers and commit ids. They look different, but that is all just visual. Subversion revisions only have been linear, because we never used branches. Have you considered that revision numbers would not match on Subversion if we commit to branches or tags, because the Subversion revision always is global aka changeset? This is by far not logical and still people did use it.

It is not arrogance, it is just a reaction to what people demanded, and if you ask for quicker work, you will have to let us use the tools we as developers need to work quicker, and better.

Git is different, but that commit id thing is just like comparing black chocolate to white chocolate. It makes no difference in the end.

Whether your mangos demons tell you they are MaNGOS 0.12 revision 6767 or if they tell you they are MaNGOS 0.12 revision 1ccdd8e2b2d7768c0777d9ac34565e3c1b5f1a69, it does not tell you more. In both cases, you will have to look up what that revision means.

I'm open for arguments, but I am not open for critics that do not fit the cause. And as I said, the developers have discussed a tool that will map commit ids to normal revision numbers, and embed these into the demons until people have learned to handle the new Git ids. Nothing else to say about the topic.

[Snake.Plissken]

M

...

Whether your mangos demons tell you they are MaNGOS 0.12 revision 6767 or if they tell you they are MaNGOS 0.12 revision 1ccdd8e2b2d7768c0777d9ac34565e3c1b5f1a69, it does not tell you more. In both cases, you will have to look up what that revision means.

I'm open for arguments, but I am not open for critics that do not fit the cause. And as I said, the developers have discussed a tool that will map commit ids to normal revision numbers, and embed these into the demons until people have learned to handle the new Git ids. Nothing else to say about the topic.

But the hashes are not linear, arent't they. How to know which hash is before another to apply changeset or other stuff. The problem is, how to reproduce the procedure to make it work in skripts, which is easy with linear number, that say not more, not less, but a megalong und nonlinear hash is not useful for other projects nor other mortal human beeings, that rely to your project. i and many many others use scripts because they don't want to update the whole stuff by hand day in day out. It's just about to get the community together again that we can work together and not the opposite. Anyway, if you're aware of this problem and step on step into our direction it's just fine and many people will be greatful.

Sincerely

[TheLuda]

All I can say is, we try to make it easier for non-Git users, or less development oriented users. Just give us a bit of time to work out a sane solution.

[Snake.Plissken]

All I can say is, we try to make it easier for non-Git users, or less development oriented users. Just give us a bit of time to work out a sane solution.

Acknowledged and thank you for you cooperation. *cough*

[Inflames]

good to see the devs doing something!

[Snake.Plissken]

Another thing, you might want to start with complete new linear revs, please start with a fixed amount of digits, like 00000000->00000001->... Why? Many of us use scripts from compiling to installing all the needed stuff and changing amounts of digits is not good, bash commands are a little limited here.

Thank you for your attention.

[webomatic]

I also think that this "move" is not such a smart move...

in any case, the revision number issue must be taken care of...unless you have an alternative like previously suggested on this thread.

my 0.02$

[Snake.Plissken]

Date + Counter

Example :

0810180

0810181

0810182

Anyway You Must Remember Last Update in Your Server

It`s Reality Easy !

Date with frequently changing amount of digits is crap, if you want to control all checkout/update procedures with all diffrent components. We dont need individual revs, we need one global linear refnumber from the relating source, hence MaNGOS and a fixed amount of digits would make it perfect for a long time without rewriting our scripts day in day out.

[Inflames]

what obout adding an file cllaed rev.h or so and is update every commit autamaticly?

[VladimirMangos]

commit != push, you can made many commits in local repo before do its push to remote repo.

And in push result your last commit can be _not_ last commit in merged after push remote repo commite list.

[IceReaper]

I think all in all this move shouldnt be a big problem if the devs would set up a detailed plan how they think development will go further.

Using git may be something that some users here dont like, but why? mostly we got an problem with patches or external projects.

Isnt the best solution to "build" a mangos-manager? A small app which can download sources from GIT with database, or whatever you want it to to, depending on its configuration. Secondly there has to be a patches-repository which the app can browse so people can simply start the app, click on "setup server" configure it what options they want to have and can check some patches they want to have in their compile. then it create a beautiful output directory with the sources/binaries whatever you want, a database folder with ONE .sql file for each database including all its patches etc etc and people will be happy.

its even possible for the devs to change vom git to mercurial, back to svn, reorganize git or whatever they like to do to make their developing nice and all they have to do is patching the manager app to work with the actual settings.

sorry for my english, but that are my thoughts about that. i personaly think i could setup such a manager but it will take me time i dont have, but it gives the devs its playground and gives the user the posibility to use mangos easy.

greetings

ice

[VladimirMangos]

Isnt the best solution to "build" a mangos-manager? A small app which can download sources from GIT with database, or whatever you want it to to, depending on its configuration. Secondly there has to be a patches-repository which the app can browse so people can simply start the app, click on "setup server" configure it what options they want to have and can check some patches they want to have in their compile. then it create a beautiful output directory with the sources/binaries whatever you want, a database folder with ONE .sql file for each database including all its patches etc etc and people will be happy.

Is devs goal make happy click-users? I think no.

MaNGOS is learning project, not only users learning, but mostly _devs_ learning. git is new tool for us also and we learning now how use it in full power. This is not main reason for switch to git but unknown tool this isn't reason not do like switch if expected better code managment

Ofc, someone can create like tool and provide it to community. And this will be intresting project for he, but not think that any from devs plan do like tool. Also note: patch's conflict resolving can't be automated for all cases. It's required human brains and programming expierience for acceptable result.

[Alex]

patch's conflict resolving can't be automated for all cases

Sure! And that is the thing that makes urgent need for linear revision tracking.

Look. I am updating code not by using SVN or GIT 'suggestions'. I took "svn diff -r xxxx:yyyy" and got all diffs I need in incremental order in that way (then analyze these diffs and make the changes accordingly). Now I have to cope with plenty of semi-random hexadecimal revision numbers I simply can't remember. More time needed to get consecutive diffs, more work, more windows on screen (one with the complete revlog is for sure now). Scripted compile system is very unhappy, too. It can't even match SD2 with MaNGOS rev and retrieve needed updates. When developing, patch revisions now need to be renamed from "no_queue_avoid_6748" to "no_queue_avoid_*nonlinear_untrackable_crap_there*" and be messed while tracked. More hand work again. Crap.

Sorry for a bit of offense here. I'm using an automated build system for developing/debugging/testing and am horrored white by the mess introduced in revision tracking.

I see that GIT is better from branching view, but there is something that must be done POLITICALLY (including updated "core_revision.h" with each core devs commit still seems to be the best way) instead of technically and everyone will be happy again.

[VladimirMangos]

But this resolve revs numbering in limited form.

Yes, svn mirror will have revs, yes if ppl remember they can report base at this revs numbers.

But we still can't used this revision for in game version output...

[Alex]

The only solution is manually incrementing counters by now. Or creating some GIT script (do not know if it possible though) that does the same for each master commit.

Thanks for the SVN import It will help temporarily, until a viable replacement for revnumber is found.

[freghar]

I won't read all 10 pages of this topic because I guess what can be found there ..

1) Git doesn't work like SVN, so don't even try to compare those two.

Some commit from mangos/master branch generated using "git format-patch mangos/master~2..mangos/master^" : http://paste2.org/p/89531

-- this is actually how git commits looks like in their ready-to-email form which should be called a "patch". It has no revnumber, but there's a date.

In fact, Git uses date and time where SVN has revision numbers, when you merge someone's branch (ie. pull from it), you will pull all his commits that he has ahead of you. And following the "one-commit-per-feature" scheme, that would mean thousands commits from users over few months ... possibly even more.

I already explained why revision numbers aren't good for distributed model elsewhere, so let me quote myself:

Actually, you probably didn't understand why it is a hash instead of numeric revision, did you? An example -- "my r344 is Bob's 233 and Alice's 81" , "hey Bob, make a diff from the r80 to r81" "that's not from r80, that's r45!".

Yes, it has some disadvantages, but many other advantages as well. Mangos used SVN trunk as the only stable branch. And if we're going to have something like alpha, beta, release candicates, possibly nightly builds, the problem with svn revisions would probably end.

PS: You can refer to first 7 characters of SHA1 commit hash as the project-unique commit hash. So you can say "this patch is based on 4bcd3f6" and you can be sure that everyone who try to apply that patch on 4bcd3f6 will have no conflicts. This worked with centralized repository like SVN as well, but it doesnt work when you get distributed.

[TheLuda]

You can refer to first 7 characters of SHA1 commit hash as the project-unique commit hash. So you can say "this patch is based on 4bcd3f6" and you can be sure that everyone who try to apply that patch on 4bcd3f6 will have no conflicts. This worked with centralized repository like SVN as well, but it doesnt work when you get distributed.

In which case you could use

$ git show 4bcd3f6

to view the commit locally.

[freghar]

In which case you could use

$ git show 4bcd3f6

to view the commit locally.

Sure, but you can't apply them in this form without the need of specifying --author in git-commit (ie. when you apply a raw diff). git-format-patch generates "commits" which you can use with git-am ..

[Snake.Plissken]

I for now will use the last changesets date plus counter if equivalent date (08101101), otherwise i use the actual date with a 00 behind the date like (08101100). Maybe this could be a possibility to coordinate actual MaNGOS state and other projects state. If the devs can't find a sollution, we need to take what we get and try our best as we did before. The problem is. not every computer uses english date conversion and needs to get converted of course

[cejkaz]

So, when I read this thread, I thing it would be practice to post any manual for patching MaNGOS from GIT. What about this ?

[BlackCat2]

Sorry for OT question but how to get git protocol through http? It's just sometimes I'm behind firewall so git protocol can't get through..

Thanks..

[Kalash]

Git is based on a SHA1 hash of commit. That way, it's not based on "rev numbers" but individual changes.

If I pull your change, it won't be different from someone else pulling your change. We will both be getting commit <SHA1 ID> rather than rev 23, 55, 1230.

[VladimirMangos]

I currently test gensvnrevision modification that undersatand git case.

I don't known what version better

1) with added repo URL

svn

09:04:28 MaNGOS/0.12.0-SVN (2008-06-03 11:52:20 Revision 6767 at http://mangos.svn.sourceforge.net/svnroot/mangos/trunk/sql/tools) (Win32,little-endian) (realm

n)

git

09:08:27 MaNGOS/0.12.0-SVN (2008-10-22 23:08:34 Revision http://github.com/mangos/mangos/commit/9d1ac1311d436cbd4f6918de636ae3732f75577e) (Win32,little-endian)

m-daemon)

2) more near to old format

svn

09:04:28 MaNGOS/0.12.0-SVN (2008-06-03 11:52:20 Revision 6767) (Win32,little-endian) (realm

n)

git

09:08:27 MaNGOS/0.12.0-SVN (2008-10-22 23:08:34 Revision 9d1ac1311d436cbd4f6918de636ae3732f75577e) (Win32,little-endian)

m-daemon)

generator use git for version creation if have .git directory and use svn case if have .svn.

[added] as i see forum understand git hash and make from it URL. So maybe (2) better and more short

[floop]

Sorry for OT question but how to get git protocol through http? It's just sometimes I'm behind firewall so git protocol can't get through..

Thanks..

Very simple

When doing git clone, use the http://github.com/mangos/mangos.git simply