In our case designers are responsible for their module tests and the release is what goes to the toplevel tests.

It could happen that a designer has already implemented and tested a feature where he knows that it will cause problems in toplevel so he wants to put an earlier version of his module in the release.

Whole toplevel regression might run for a week.

This means that if developer A commit new things, developer B needs to update his work with the changes from developer A before he can commit his own changes.

I’m not sure you’re working with developers, but you should have automated test. As soon as developer B merges his code with that of A, all tests should still be working. If not, don’t commit it!

Assume many designers are working on one project and everyone checks in his latest changes to the trunk. So the trunk will not be stable. To build a stable release some some parts have to be taken from earlier revisions.

So I could write a mail to all developers an ask them to copy their last stable version to the release branch.
Then I have t wait till everyone answers that he is finished, and pray that everyone has copied all files needed.

Is there a script available which can automate this.

The idea is to have a PHP generated view where each user sees all his files with the latest version. It should be possible to select earlier file revisions and the php script then should copy the marked revisions onto the revision branch.
A logfile should hold the info who has committed which file revisions to the branch.

I come from ASIC design and we have a CVS based standalone tool for that, but I would like to move to SVN and get rid of the standalone solution.

I plan to code this in php but first I want to check if something similar is available.

Perhaps someone who reads this has a solution.

regards
Martin

Thank you for this post, it is very useful.
I once read about that the difference between a stable branch and non-stable branches was in numbers, let’s try to apply this to your example. Please correct me if I’m wrong, I’m here to learn. :)

In your example 1.1.0 would be a non-stable version. If we consider that it’s allright after adding some code and we want to make a stable branch (and a tag as well?) we would change it to: 1.2.0 (changing from an odd number to an even number).

Thank you for your post.
Regards from Spain.

The best way to handle this, in my opinion, is to create a script that can compile binaries from a given branch. The developer should invoke the script when he signs over the branch to the testing department.

You could probably do something nifty with post-commit hooks, which could build the binary automatically after a commit.

We want developers to work off of “trunk”. When they are ready to release the software for testing, they would use the “branch” and create a new branch. However we want the testers to only get binaries & not the source code. How do you recommend we do this? Should we create a branch and the developers do a SVN update of the code in the branch and then make a new build and release that build to the testers?

Please let me know.

Thanks

The upgrade scripts would be massive and it would take many hours to run in just a couple of new objects. When all i want from my config management tool is for it to understand which files are in a release and to only extract those files.

I run a 8 terrabyte database with 50000+ objects. To use this method and go through each table and look at the versions would be crazy. We dont run several different versions of the DB only 1 so the ruby approach would not be much help.

I would have thought it would be a simple SVN issue to only package the files that are needed for the release rather than the entire branch???

I thank you for your help…

9-5 Frustrated :-)

Read http://api.rubyonrails.org/classes/ActiveRecord/Migration.html for more details about Rails migrations. It may give you some great ideas to solve your own issue.