Leaderboard

Didn't read the whole thread, but I find it kind of funny, that people still show up after 15 years of successfull development and tell us we're doing it all wrong...

Thanks chakkman for your views, I've been hoping to hear feedback like this from the community. (in my view): I get your point that pagans should be distinct from other factions as well as believable. The Thief franchise succeeded on the first front, but Thief 3 only did so by making caricatures of them. In my recollection Thief 1-2's pagans were more subtle by comparison, but they too had a peculiar way of speaking (my copy of the game was French so I missed the finer points of what they said). It does make them stand out, but it may still be too out of place for TDM's low-fantasy universe. My way of balancing the 2 needs - character & believability - was to imagine a superstitious man who believes in beings out of folklore tales and who lives by more primitive ideals. Thus I've written lines like: The way I see it, most of those living in a pagan society would live fairly ordinary lives, albeit within the ruleset imposed by their pagan beliefs, while a subset of the society's members deals more intensely with the mystical side: the shamans. As a result, a good deal of this pagan's lines could've been said by someone else as well, though overall it should be apparent that more gruff formulations are used, in keeping with a rough way of life. That's my understanding of what a TDM pagan is. Everyone is welcome to suggest changes to this concept, or point out if they think current lines don't capture the desired concept. @chakkmanresponding to your suggestion to include more references to nature and mystical beings, my original 2010 draft featured numerous lines referencing trolls, a dark lady, deities, a spirit wolf etc. Some years later they seemed to me to be too high fantasy and intrusive for what should be a believable human in TDM's setting, so I toned them down/cut them/gave them to the shaman subset, but I'm flexible in this decision. If the community considers these a good addition I can bring them back.

I'm a little surprised that some people here view Alberto's suggestion as an attack because although his style might seem a bit brash, he is obviously only trying to help and it's not as if what he's suggesting is something that is totally out of line. He's passionate and wants to help, what's wrong with that? If newcomers and/or new suggestions are met like this then what will be the future of this community? Opinion doesn't need to be attacked, it can be viewed as an opportunity.

Oops, I did not realize it was about DR

I did not say that distributed functionality is what makes git hard to use. I said that git in particular is such that it is hard to use. Not because it had to be so, but because it so happened. You seem to bring another misconception here which I often hear: "You are using svn up and svn commit with SVN, so in git it would be the same but also there would be git pull and git push, nothing hard at all. And you don't need other commands or much knowledge for daily use". The reality is that after a week or month of daily use, people will have a choice of either learning the substantial part of how git works (which is much more complicated than SVN) along with some advanced commands, or suffering from their limited understanding of git.

I'm a big fan of Git. I switched DarkRadiant to Git years ago, and have been happily using it and sharing commits between my and Greebo's repositories (on entirely separate hosting platforms) since then. But even as a Git fanboy I am embarrassed by some of the misconceptions about, both in the "for" and "against" camps. Misconception: "Git doesn't use a central server". Reality: The vast majority of Git projects, and the workflow that would most likely be adopted by TDM if it were to switch to Git, is to have a central authoritative server that every trusted developer pushes their changes to. The Linux kernel is a notable exception, but is also very atypical in both its size and the distributed nature of its development. Git provides a little more flexibility in that developers can make a whole string of commits locally and then push them in one go, but they are still going to be pushed to that central server before anyone else can use them. Having each individual developer push their changes to their own GitHub repository and submit a pull request would be possible, but probably wouldn't solve any problems for this project, and would increase workload for whoever is appointed to review and accept all of the pull requests. Since all developers would be pushing to the same repository, code breakage is just as possible with Git also. Misconception: "Git magically avoids code conflicts". Reality: Code conflicts are the result of divergent, incompatible text changes in the code itself. If you and I edit the same line of code and then try to push our changes, a merge conflict will happen. The choice of VCS makes absolutely no difference to whether this conflict will occur, although Git does provide slightly better tools for dealing with the conflict when it does arrive. There are only two repositories that matter for the Dark Mod: the source code repository, and the assets repository (which is never going to be switched to Git because it is a repository of large binary files which would not be handled well by any distributed VCS tool). So needing to clone the whole thing is not an issue. Those are both workflow or cultural issues which cannot be solved by a VCS. People can just as easily delay commits/pushes with Git, and they can easily make lots of small incremental commits using Subversion. If commit frequency is a problem (and I have no reason to believe it is), it needs a social solution, not a technical one. On the other side of the fence: It does have unsafe ways to edit history, but they are not particularly "encouraged". Most Git guides I have seen make clear that rewriting history is very dangerous, completely screws up other people's work, and should be avoided whenever possible. Sites like GitHub even have the ability to administratively disable force-pushes altogether to stop people from doing them accidentally. Misconception: "Git adds a whole load of distributed functionality making it hard to use". Reality: For the most common use case (pushing to a single central server), there is absolutely no need for any Git user to deal with "distributed" functionality. You can produce a SVN-to-Git cheat sheet that maps commands almost one-to-one, and stick to those commands entirely. Some of the commands aren't particularly well-named (e.g. using "checkout" to switch to a branch, or "add" to add changes to a file rather than adding a new file), but they are not complex to use, and you can always set up aliases if you find the default names confusing. Conversely, many operations are significantly easier (and faster) in Git than in SVN. Only recently did SVN add the ability to view the diffs of each change in the history, or to show which changes were pulled in by a merge, and these features are still slow and cumbersome, whereas Git (and Hg) did all of this from the beginning.

Guys, guys, I am sorely disappointed by the lack of "we's, be's, we's, woodsie's" style speech for the TDM pagans ! For shame ! More seriously, I'll read your posts later this evening. My feedback is coming.

@stgatilov

@greebo