Looking for ideas for a tag/release svn usage model

I work for a small company that is using subversion for version management
of ASIC design files. The current way svn is used is for all development to
occur in the trunk. Each designer checks files directly into the trunk when
they feel their changes are good enough. There exists a set of tests,
called the "sanity" regression, that designers are *supposed *to run before
checking things in.

The problem, of course, is that top-of-tree frequently breaks. People try
to save time by only running part of the regression test suite, or they
forget to check in all their changes so things pass in their work area but
not for anybody else, etc. So we'd like to create more of a "release"
model, where checkins aren't flagged as "good" until *after *they've passed
a set of tests in a clean tree, and other designers won't see unreleased
changes from others, unless they specifically request them.

In prior companies, I've setup scripts to do this using CVS. We let
designers directly check files into the main code tree, but to "release"
files they ran a special script that would gather up their changes, run some
tests, and if the tests pass apply a special "stable" tag to the files. CVS
allowed you to sync your work area to tagged versions of files (I think CVS
calls them "sticky" tags), but have individual sub-directories synced to the
top-of-tree for commits.

Now I'm trying to figure out how to apply this sort of flow to svn. I think
it would be fairly easy to have a script that runs a regression, and if it
passes, does an "svn copy <passing work area> http://.../tags/good_version"
to update a tagged version of the tree. But then how do users make use of
this tag? Seems like they could use "svn switch" to move their work area to
the tagged version, but then their commits will change the tag, and we don't
want that. We only want the script to be able to update the tag. I'm also
reluctant to try any flow that requires people to use "svn switch", since my
own experience with that command was less than pleasant (it's easy to really
mess up your work area if you don't specify directories in the way svn
expects them).

Is there a way to "update" your tree to the versions of all files that are
contained in a specific tag, but without "switching" your work area to that
tag? Or am I going about this the wrong way? I realize svn doesn't really
version individual files, but if a tag is by definition copies of files from
various trunk revisions, then you can think of this as versioned files (e.g.
each file has "a version" corresponding to its last change in the trunk).

Is there an easy way to allow people to update parts of their trees to a
tag, but then not be allowed to directly submit changes to this tag?

The big caveat is that our svn users are not very advanced in the ways of
svn. So we can't change much in their existing usage, e.g. asking users to
create private branches and integrate their changes into the trunk would
probably be asking too much.

-Brett

-- 
Brett Coon - brett.coon@gmail.com - http://brettcoon.smugmug.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389606
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].