I work for a company that makes a web based tool. As part of my job, I was given the task of release engineering for this product(something I had never done before). I've setup the following system using SVN(Sorry, we can't use another repository before someone suggests switching to GIT or perforce or one of the myriad of other options!)
Trunk is what is on the production servers at all times There are 2 branches open at any given time 1) Maintenance release. This is released every Wednesday 2) Sprint branch. This is released by weekly(on Wednesday with that weeks maint branch)
Prior to release I merge that weeks branches into the trunk.
I have found that when running svn merge, it usually creates a ton of problems when it merges. We have thus switched to a manual merging meeting once a week, which takes anywhere from 10 minutes to 1 hour, where I literally winmerge the 2 directories on my system and ask each developer "was this your change? which version of this code should we keep?"
This system definitely is NOT ideal.
Can someone suggest something better?
First of all, SORRY! I don't envy your position.
I worked for an international bank doing web redesigns for the Federal Card Act. Same situation as you, only likely on a far larger scale. We had 3 people that did nothing but release management on a very similar schedule. The thing that made it do-able (in some weeks I worked with a couple hundred files at a time) was the fact that the developers merged to trunk, then trunk was deployed to production as a copy....we didn't check directly into production. So, from a release standpoint, you might be helping corral developers to get their work checked in (what's the difference between doing a "update" or answering "is this the right version?" really) But then you're not blindly choosing which updates should be going live, which seems like a major problem. Sure, developers might complain a bit, but having been in that position it's really not too bad. And if you make yourself available to answer any questions that might come up, it should be ok. It worked for the 1,200-odd developers we had working in 4 locations nationwide.
The other thing that this buys you is time to test. If code isn't merged before it goes live, how can it be tested in the context of the bigger system? I sure hope the answer isn't that it's not being tested!