News on 1.4 and subversion

#1 Subversion will not be given out for 1.4. All Torque releases are going to an installer-based system which is standard for most 3d Engines. Torque is now in a very stable form, and we are working on some major changes that will break backward compatibility in the next year, most notibly the component system. This is why we have switched to a Subversion repository, so we can break things.

#2 @pat

Thanks for the response. I'm still not sure what this means to us as developers, so maybe if I try to summarize, and someone can tell me if I'm wrong?

The installer based releases means that we will not be able to access incremental versions on a server. So no more accessing head each day to see if any fixes have been posted?

The subversion thing is then something that you at GG are going to be using internally? Why has there then been so much talk about it? If it's only an internal process why do we need to even know that you are using it?

Does this mean that we will not see the component stuff, or any fixes until 1.4 is released?

I have to confess that I kind of enjoyed checking pretty frequently to see if any fixes had been posted to HEAD, and was surprised to find that they were pretty often, and often felt relevant to my project, or at least interesting.

#3 Right now, that is what we are talking about. CVS has been a huge pain in the ass, to put it mildly. I'm not sure why people are buzzing about SVN, one of those crazy marketing guys probably told someone about it. Again, nothing is final, but right now the plans are not to have everyone with access to SVN. We are moving to a 3-month Torque dev cycle where we will have a minor version come out roughly every 3 months. This means that we will be planning (when I say 'we' I mean "Ben Garney") what features will be in each revision (And oh what plans we have) and when those are in, we will release a new version. It's not going to be a random/slow plodding along of feature additions.

#4 @Pat

Thanks for the clarification. I can see how CVS would have been a pain for you guys. For me, however, it was kind of nice to follow the changes to the code base on a day by day basis. It meant that I could integrate each change into my code as it was made to head, and that was a lot easier then integrating a slew of changes with a new .1 release.
Again, I can see how this will be easier for you guys, as dealing with the uproar when someone checked in something to HEAD that wasn't perfect must have been a major hassle.

#5 Pat, I think that's a great way to go. God knows how badly CVS has treated me in the past(it's a living thing, and it hates- it hates so much...).

#6 Man, I loved checking cvs a couple of times per week. Always fun to see a new great feature added, when i've just had problems with code for the last 20 hours :)

#7 Actually, Pat's info is a little out of date (but things change rapidly around here, so that happens once in a while).

It's true, we won't be giving Subversion access to everyone (it's too much of a pain, given the way Subversion does user authentication).

It's also true that we'll be doing SDK installers, to make it easier for everyone to download and start using Torque (it's proven to be too much of a pain having people who aren't familiar with source-code revision control software go through CVS).

However, we will also be doing code drops into CVS from our internal Subversion repository periodically more frequently than when we do major releases. CVS won't go away if you want to continue using it.

Now, we didn't want to exactly announce all this just yet, but since the cat's outta the bag a bit, here we go. :)

It's good all around. Three benefits:

1) We have a private, internal place we can play with the code, try cool stuff, and not worry about breaking things out in public and screwing people up.

2) Everyone will still have CVS access, and we'll be doing code-drops into CVS quite frequently. So, you'll see updates just about as frequently as you've been used to, and can get your hands on the cool new stuff we'll be trying without having to wait for the next version of the SDK installer. :)

3) With SDK installers available, nobody will *have* to use CVS to get an up-to-date, stable version of the engine. That will make it easier on lots of people (and easier on us, freeing up a lot of support time, which means we can pump out even more cool stuff).

Pretty rocking system, I'm glad we're moving in this direction. Watch for more info soon. :)

#8 That sounds like an EXCELLENT plan, Josh. I especially like the idea of your guys having more time to pump out good stuff while making things better for the rest of us!

#9 Hi,

I just wanted to say that except for a couple of minor issues with uppercase/lowercase, deleting and renaming files SVN is an awesome concept. My team was using CVS until about a month ago when we switched to SVN, and I think this is great. SVN has som many advantages to CVS that there are too many to mention. The best thing about SVN is that it uses binary backups instead of text, so if you change a file the only thing that SVN keeps is the binary change(smaller chunk) instead of the whole file (CVS).

Marrion

#10 Instead of a read-only CVS (you are talking about dropping code out of subversion into CVS periodically) why don't you offer it via RSYNC? . It would probably be a lot simpler to administer than CVS.

I like the idea of the installer-based distro. For people like me who don't need the bleeding edge, installer is good.

#11 Quick question:

does SVN accept patches in the CVS style we'd been submitting?

what will be the correct and good way to submit stuff to yall?

#12 The combination of the installer based delivery, and the code drops into CVS sounds great. It sounds like the best of both. Good idea. I personally will still access CVS periodically to check to see what the latest is, but new users will get a clean install of a stable code base, and there should be fewer complaints from people trying to figure out CVS.

#13 Paul,

Patches are (usually) nothing to do with the SCM behind the scenes. You'd just apply the patch to the local checked out copy of the source, test it, then check it in. The process, at least technically, is not really any different.

T.

#14 What is the problem with Subversion's authentication mechanisms? mod_dav_svn under Apache works great, and you can use simple htpasswd files to control the user account, pretty much the same way as CVS's pserver normally did things...

In fact, (haven't tried this yet) but it should also be possible to use mod_auth_*.* for controlling access to an SVN repository.

I'd really hate to have things dumbed down, just so that developers that don't understand revision control systems are more comfortable with getting the source code.

#15 Roelf, it's not dumbed-down at all. Advanced devs like you can still access the CVS repository and get updates as per usual. If anything, you should be seeing more frequent updates in the CVS repository than before, once we get rolling full-steam with the new system.

#16 Phew! :)