Zandronum 1.0 Released

After nearly 2 years of development, Zandronum 1.0 has finally been released. For those of you who don't know, Zandronum is the continuation of Skulltag. Here's what Torr Samaho, the creator of Zandronum, had to say on the Zandronum forums:

This is a major milestone for various reasons. First and foremost, it is the first public version of Zandronum and thus ends the awkward situation where most of the servers are still running Skulltag 98d even though Skulltag has been officially declared dead by its creator and the community migrated to Zandronum.

The development of this release started almost two years ago under the name 98e. What was originally intended to be a small bug fix release grew into much, much bigger proportions. The two most striking differences changing our development model are the opening of the source and the creation of a Skulltag fork named Zandronum.

The long development time allowed us to make truckloads of changes to the engine. There are too many new things and fixes to highlight all of them, so let me just list some very remarkable ones:

• 3D floors in competitive modes and non-sloped 3D floors in the software renderer
• considerably improved client side prediction (try some bridge things)
• numerous new ACS commands (ResetMap anyone?) and the GAMEMODE lump that allows the reconfiguration of hard coded gamemodes (e.g. Coop with teams, LMS with spawned map things)
• an almost unlimited number of big and small fixes for things that have been plaguing Skulltag for ages (for instance the weapon synchronization is completely redesigned, putting an end to many of the problems inherent to the old system)
• 64 player support
• reduced monster bandwidth usage
• auto return system for the Terminator sphere and the Hellstone, making Terminator and Possession finally playable on all maps
• "unblock players" flag to allow hordes of players play cramped maps with few player starts
• much improved Hexen support
• flexible forward skipping in client demos
• much better poly object handling online
• externalization of Skulltag's resources (existing Skulltag mods are still fully supported, but need to be loaded with compatibility wads to supply the Skulltag assets)

So head over to http://zandronum.com/downloads/ and check it out!

Bots had better still work!

Yay. Now if only (g)zdoom also used a modern scm like zandronum :)

Very cool multi-player port. Runs well!

Hirogen2 said:

Yay. Now if only (g)zdoom also used a modern scm like zandronum :)

What's wrong with SVN? For these projects it's more than enough.

Graf Zahl said:

What's wrong with SVN? For these projects it's more than enough.

While I'm not going to be able to come up with a solid enough argument to convince you (or Randy) to switch. The ability to have source code management offline has proven to be quite useful for me. In addition a Mercurial clone often takes less time/hard disk space than an SVN checkout and you end up with the complete history locally. (Which makes finding what revision a change occurred much faster.)

To me, it's one of those things where you have to use it to fully understand the benefits, and it does go beyond just hypothetical points.

But can't you import an SVN repository into a local Git or Mercurial rep? I'm pretty sure it's possible.

Graf Zahl said:

What's wrong with SVN? For these projects it's more than enough.

Get with it, granddad, it's all about Git and Mercurial nowadays, don't-cha-know? :P

Joking aside, I've been enjoying using Git for other projects (besides Chocolate Doom). The main reason I haven't switched Chocolate Doom over yet is that (1) I'm not satisfied with the Subversion-Git import tools I've used and (2) I'm worried that doing so might upset Quasar/Kaiser - though that's less of an issue now that the Strife work is mostly complete.

I just messed around with an Odamex fork on Bitbucket using mercurial and hgsubversion, and it was ridiculously easy. It's at least worth playing around with.

Gez said:

But can't you import an SVN repository into a local Git or Mercurial rep? I'm pretty sure it's possible.

Sure. I'm sure there's some pitfalls though since that's basically like asking "Can't you just run the Windows binary on Linux?"

There's really no good reason for a new project to use SVN. Especially with Bitbucket and Github providing unlimited free hosting (both public and private for Bitbucket at least).

I'm not talking about starting a new project. I'm talking about stuff like people working on a centralized project hosted on SVN, and cloning that into a local git/hg repo so that they can work on their own little experimental branches while keeping revision control and still be able to commit to the SVN rep when they're happy.

Gez said:

I'm not talking about starting a new project. I'm talking about stuff like people working on a centralized project hosted on SVN, and cloning that into a local git/hg repo so that they can work on their own little experimental branches while keeping revision control and still be able to commit to the SVN rep when they're happy.

I am able to clone SVN repositories into Git by using the free SourceTree client for Mac, yes, and pulling SVN updates will work too. Hopefully pushing will work too. I haven't tried it with any utilities in Windows, though. Surely there's one.

fraggle said:

Get with it, granddad, it's all about Git and Mercurial nowadays, don't-cha-know? :P

Joking aside, I've been enjoying using Git for other projects (besides Chocolate Doom). The main reason I haven't switched Chocolate Doom over yet is that (1) I'm not satisfied with the Subversion-Git import tools I've used and (2) I'm worried that doing so might upset Quasar/Kaiser - though that's less of an issue now that the Strife work is mostly complete.

I ported Skulltag SVN repository to Mercurial by way of git-svn and then hg convert. I was seriously not impressed by hgsubversion's lack of handling svn merges, but git-svn seems a lot smarter to me. What problems did you run into?

fraggle said:

I'm worried that doing so might upset Quasar/Kaiser - though that's less of an issue now that the Strife work is mostly complete.

Pfft, just another thing to blame on you. :D

AlexMax said:

I ported Skulltag SVN repository to Mercurial by way of git-svn and then hg convert. I was seriously not impressed by hgsubversion's lack of handling svn merges, but git-svn seems a lot smarter to me. What problems did you run into?

It's complicated and technical to explain, but essentially, at a couple of points in Chocolate Doom's SVN history I've moved the locations of some branches and tags around (the CVS-SVN conversion gave a suboptimal layout). A decently done Git conversion should be able to reproduce the history as it appears in SVN, but git-svn doesn't (it seems to work by replaying the SVN history commit-by-commit).

I created this tar file a while ago that shows what I mean.

It seems more of a result of Chocolate Doom's svn history not exactly being optimal itself; short of rewriting the svn history entirely it's not really fixable. Even if it was caused by an old and buggy (but new at the time!) cvs2svn.

I still think Chocolate Doom's repo would make an excellent test case for ESR and his reposurgeon tool :)

Graf Zahl said:

What's wrong with SVN? For these projects it's more than enough.

For ZDoom/GZDoom the much better branch handling would be very useful. You could define GZDoom as brach/fork of ZDoom and let Hg do all the merge work (keeping the full history instead of collapsing many ZDoom commits into a single GZDoom commit). This would also be interesting for Zandronum because I could then define Zandronum as GZDoom branch and also get the benefits of the much better merge handling.

Also you can more easily import code submissions using Hg's pull mechanism.

What's the difference between Mercurial and Git?

They are two competing distributed revision control system but with very similar feature sets. I prefer Mercurial because it has better Windows support than Git (at least it was like this when I switched to Mercurial).

On the outside Mercurial and Git do virtually the exact same things, although their internal implementations are 100% different; Mercurial being written in Python allowed it to be run more easily on Windows much sooner than Git, but I hear that these days Git is just as well supported.

I personally use and prefer Git -- nothing particularly technical but the UI and command line set of git just generally seemed to make more sense and mesh with my mental model. Mercurial's never clicked with me no matter how much I've tried using it.

EDIT: Oh Jesus I forgot: Congratulations on a great release!

Gez said:

But can't you import an SVN repository into a local Git or Mercurial rep? I'm pretty sure it's possible.

Yeah, at least hgsubversion for Mercurial makes this extremely easy.

printz said:

What's the difference between Mercurial and Git?

Mercurial is better because it has a crazy plugin system. You can use it with Git and Subversion repositories. It's sort of the VCS to end all VCS's. Bitbucket - an online Mercurial host - supports Git as well as Mercurial.

Github (Git's analog to Bitbucket) is Git's killer feature really, although it's primarily hype. The vast majority of projects on Github are Ruby/Javascript/Python, i.e. web developer projects, and those guys are more apt to write their own blog, host their blog code on Github, and then blog on their blog about how Github is great.

The nice thing about Git is that it's super fast. Large repositories, old repositories, or crappy network links will make you love that characteristic.