Update Protocol, react please

[Fireburn]

I don't see the point of creating a branch for each weekly build. On average, we develop weekly builds Saturday and Sunday evenings, with around 5 changes to the gamemode. Creating a branch for five changes is a little far fetched. Fair enough I can understand things need to be tested, but why can't they be tested before the developer commits them? Most weekly changes are really minor tweaks and would require just a quick five minute test with another player. If we only commit things after they've been fully tested, trunk will remain stable.

I will explain why in the following part, I wrote this post from the last part to this, instead of doing it the usual way.

If a circumstance occurs where a developer does make a lot of changes and they can't commit until the branch is created, which is on that Sunday, commiting lot's of changes to one revision isn't to good because it increases the chance of conflicts and makes it harder to revert changes in the future.

I think you're getting it wrong, my point is that you can still commit throughout the week. However on the sunday we will get a build ready for releasing. We don't want halfly finished stuff inside the trunk anyway, so it would still be the same, with the big difference being that the update starts at 6.40, and all code before 6.40 gets in instead of all code before 22.30.

Additionally, over the weeks we've been most actively developing on a Sunday night, prior to the update. If we have to commit changes before 6.40 some of us may feel rushed to complete code or any important bug fixes, which may result in further bugs. It's stupid dis allowing commits before 6.40 - what if a bug is found during pre-update testing and a commit is needed before it goes live?

It's true that most of the stuff gets done sunday, however, if we have a properly functioning betateam, we can test it for a week, assuring there will be less bugs in live server builds. And the deadline isn't a rushing deadline, there is nothing wrong with adding a function later than the deadline, it will just be tested for a week, and will be put online the week after. I've been updating for a few months now, and there are times some weird fuckups sneak into the gamemode, which take hours to solve, resulting I am late in bed again, with creating a branch around 6.40, we will have the whole day to fix it. And about bugupdates, it's quite easy getting them into the branch, will require some copypasting, but this way reduces stress levels, because an update can be ready say 16:00, instead of 23:00.

It's pointless making a backup of the compiled version. If a problem occurs and we need the older version, what good is the amx? The full source can be reverted using tortoise svn.

We always done that. Why? Because when an update goes wrong and some way fucks everything, we need to be able to downgrade within a minute. By backing up we can be sure that can be done. You don't want an offline server while searching through all commits trying to find what possibly is wrong, or what possibly crashes the server.