Okay the other thread was going OT (as in, less pertaining to Spring and more pertaining to general development), a good deal discussing merits/whatnot of git, so i figured might as well start a new topic to flesh out the discussion indepth
Tim Blodjik wrote:
I did, but Linus is not such a good speaker, he is comparing his software with other software for his use case and then flame you for being stupid if you don't use his software. I mean I know svn is not perfect for Spring but he did not explain to me why git would be better. My main problem with svn is that we can't do map development with it as it won't allow large binary source files. This issue seems not to be on the radar of people like Linus.
Still you guy's explained some things, if we move to another system that has some advantages then I'm fine with it.
What you're addressing first is Torvalds' style. He tends to present his views in very combatative ways. Is he an asshat? Yes. Has he earned the right to be a asshat? Yes, in a way that few other people really have. I suppose one could make the argument that his strong words can force people to defend their opposing ideas more vigorously than they might otherwise.
For technical concerns, This page serves as an advocacy as well as newbie guide for git. What's most interesting is that it says that "git" itself is more of a file system; the source control stuff is built on top of that. Yes, large blobs are supported. How "large"? Haven't quite found out anywhere that says it. You could always just put some map sources under a git repo and find out how it scales, of course
The heurestical line-change tracking across files and other cool stuff) is of course restricted strictly to text files. It doesn't make sense otherwise. I actually am curious as to how git handles changes across non-text files, or if it even bothers at all and just compresses them as best as it can in whatever branch it came from.
BTW, if anyone can figure out how the heck to get GIT to ignore certs when https'ing to a SVN repo, please let me know. the GIT_SSL_NO_REQUIRE thing aint working right for me :\
Smfgbjwh?!
Since when has Linus Torvalds been discussing the development of TA: Spring?
I think GIT is probably a good idea if you have _lots_ of developers (like Wine, or Linux), but something distributed like bazaar could be interesting, because you could make the large files reside just on the mappers' machines until you decide to do a release (or something).
Wheeeeee. I read through just enough to realise that:
A. I get the idea that it's faster than SVN, and has a very interesting, non-linear approach to version control.
B. I strongly suspect it'd be a very weird thing for Spring development, since we still very much rely on a release manager, and it'd lead to a great deal of complexity in terms of patch-submissions.
One of the things about Spring's development, as software, is that there's always a useful level of back-and-forth, between coders who've been working with Spring's source for awhile, and actually understand big chunks of it, not just the stuff they've personally written, and all of the people who're submitting new features, or proposing fixes.
Now, this model would break down, pretty fast, if, say, Tobi and Trepan both left at the same time. And it's always highly dependent on the skillsets that are currently around- different developers have brought different things to Spring, many of which, frankly, have not been fully exploited yet.
At any rate, if Spring grows, which may or may not ever happen (this LUA stuff could very well do it, but we shall see) then git may make more sense, because the developers will want to allow more and more folks to be able to contribute patches "on-the-fly", and the current reliance on builds on buildbot and game designers reporting bugs along the way, might be less of a big deal, since revisions and merge controls might be what a release manager really needs, to stay on top of a surging mess of code. I dunno- our current system is working fairly well, and Spring's overall development is stronger now than I thought it would be- I honestly expected us to be in the middle of porting to Command Engine by now, but I think, with Trepan's outstanding work, we have a lot of life left in the engine.
With SVN, even a dummy like me can see what's been fixed or added recently, through the Web display or by looking at Mantis, and know what to expect when Buildbot delivers a compiled installer- what to test, what might be broken today, what might be new and interesting to play with.
I tend to do that in chunks of time, depending on how vital it is- right now, for instance, I'm too busy working on my game, and learning what LUA can do for me, to bother, but I will almost certainly put my eyes back on it, as we get closer to a release, and do more testing. At any rate, the current system allows game designers to get a window on what's going on, in a linear, timestamped fashion, and between that and Buildbot, we have at least some clue about what's going on, and what we're going to need to be ready for / integrate into our projects.
A git system might mean that we have no idea what's going to happen, what features will get cut or lost or mangled, and we cannot really advocate for them if we don't know they aren't going to be in the final merge. It'd muddy the water, and I'm not sure I see the direct benefits.
However, I should point out my own biases- I'm very tight-lipped about what I'm doing, and I'm not running an open house. However, all of the more open projects and their developers seem fairly content with the system, too, and in fact some of them have contributed quite a lot of source to Spring directly- far more than I probably ever will- in order to get what they need, and they've gotten it.
I benefit from this system, where I can see what's going on engine-wise, but do not have to let people see what I'm doing, and I'd be pretty lame if I didn't admit that that's one of the things that helps make things work for me- the developers aren't likely to screw around with me on purpose, because they can't see my side of things, and I, in turn, mainly just look at what they do, and make an issue out've it only when it's worth fighting for.
Which keeps things stable, not just for me in particular, but for everybody, imo, because all of the people like me aren't able to rule the development process, yet we aren't left hanging, the vast majority of the time.
Sometimes, I'll request something, and I won't get it, or it'll be too late to actually matter, and if my idea sucks, and has no traction, then it'll never happen. And that's not a bad thing, even if it sucks, personally.
It's a good system that way- game designers don't get features that they won't use, and when multiple designers actually agree on something, it tells the developers what we're wanting, without us having to show all of our cards all of the time. Git would make it harder for the game designers to have any expectations, and would probably make it harder for the release manager... and, er, I still find it amazing we haven't worn Tobi out, he's lasted longer than any of them, other than Yeha, iirc.
This is all just my opinion, of course, but since most people's reaction to your threads has been, generally, "we're using SVN, and we don't see the benefits" or "wtf are you talking about Dragon, get a life", I thought I'd give you another perspective on this, which you may not like, but it's where I come from.
Git would probably destabilize things a lot, because developers with really crazy ideas could wreck game designs, if they weren't stopped well in advance, which is what generally happens now, where a big, system-changing commit requires consensus between all parties.
And I dunno about Smoth, Nemo, Warlord, etc., etc... but I don't have time, or the energy, or the soul, to police the developers, nor do I want to.
You seem to be assuming a lot out of nothing again, git is really just another version control tool. Just one that makes (local) branches easier. It's not that people will stop committing stuff to a central repository. It just helps development.
In coding you often want to commit just some small parts of the changes, and keep others local while you work on them. Committing to a central rep is still the final goal, and you'll still be able to see changelogs online.
@jcnossen: Of course you are right, but I do agree with Argh post - many of the posts about Git presented it as a 'revolutionary' thing, that has just good sides. As you said, local branching is easiear, but besides that, as Argh pointed out, I fear a to 'distributed' development model will impose a big burden on some of developers to track patches and generally track the development.
But I will be curious if this would work... :) I never worked in a team bigger than 7-8 people that modify the same code, so I accept things might be different.
Well, the most important thing about git is that it can do what svn does (i.e. a centralized repo) better than svn *can*. That alone is a winner. Distributed comes next - it means that someone who doesn't have central push access (that is, something like commit access in svn), can still commit changes to his local tree. Other people can then pull those changes and, if they have that magical commit bit set, push them to the central.
Of course, the big deal about distributed is that there needn't be any central. This doesn't make sense for releases, but it doesn't have to - it is assumed that the current project maintainer (i.e. Tobi) owns the tree that will be used to make a official release. Simple.
Argh, I didn't read your rant, but judging by just its length, you don't get what distributed is about: trust and freedom. Tobi says he has the official spring source (he's the maintainer after all) - and we all believe him, clone his repository and ask him to pull from us. If he's lazy, he can allow some of us all to push into his repo. No need for a technically defined center - but you can still have one, as you can see.
To elaborate, GIT and a host of other distributed models for *stuff* rely on what's called a "web of trust". It's demonstrated most spectacularly with PGP, where the web of trust is used to determine whether or not a particular signer is being honest about his identity.
GIT doesn't enforce such a web of trust model explicitly, but relies on a special web of trust implicitly like so many other applications do: it's the one in your head. I trust a certain number of people absolutely. They can push onto my repo, they can pull from my repo. However, I don't know all the people in the world, and only trust a small handful. The people who I directly trust in turn trust others - so then we can build a "web of trust" (hence the name), and patches can propagate along that web until they reach whoever uploads the source.
This means that noone really is "in control", but there are a few people who serve as the gatekeepers. Part of the problem with SVN is that it promotes nutty politics for commit access and can especially frustrate people who want to make sporadic, helpful, contributions, but don't want to wade through the political crap to do so, and don't want to have to bug people who do have commit access five times a day to get even one patch committed.
(Yes I am speaking from experience; when Spring was only a few months old, I wrote a small but much-requested patch that allowed health to be settable via script. It was never implemented, despite multiple emails to the devs, several threads, and other various things. You can imagine why I didn't bother coding anything for this game after that )
@imbaczek: I do not know exactly how git does 'centralized repo' better than svn. And distributed could or could not be necessary - Tobi can say it owns the tree even now. Were there many problems related to that !?
@Dragon45: The web of trust exist even now. If Tobi trust X and X trust Y all it has to be done is for X to ask commit access for Y. It is simple. I doubt Spring has 1000 developers so that this becomes a problem.
And about your experience, I fail to see how git would have been better. Nobody 'trusted' you to commit your patch. You had the option to branch or not. It is exactly the same with git.
(edit) I just read at http://utsl.gen.nz/talks/git-svn/intro.html that partial checkout is TODO in git. I know that in Spring everything is put in one directory (and don't like it much), and anyhow it checked out fast enough for me, but this doesn't sound good.
Also I have used with success for projects svn:externals. (and it was what I was looking for)
Many arguments are related to distributed and web of trust, I do not say it will not work, I am curious if they really work better or not - from an experience point of view. Most of the things come with a tradeoff, it would be nice if git wouldn't but I would like to hear that (or what the tradeoff is) from someone using for Spring (or other project) for some time.
malric wrote:@imbaczek: I do not know exactly how git does 'centralized repo' better than svn. And distributed could or could not be necessary - Tobi can say it owns the tree even now. Were there many problems related to that !?
svn doesn't have local branches and sane branch merging, local commits and fast/offline access to history.
Also, if you want to collaborate with someone on developing a feature, you don't have to pollute the central repo for that, you can simply pull from each other.
BTW partial checkouts are a problem, but TBH many things that currently are checked in to svn don't really belong there; they are completely parallel projects and if/when spring moves to git, these should be put in different git trees.
I've got mixed feeling about svn:externals, I believe it has it's uses, but they're pretty limited IMHO. (spring doesn't use them after all, and it theoretically could, e.g. for streflop/zlib/etc.)
