I had a similar problem a while back when trying to coax a VSS group to
SVN. My general advice is to really push them on the paradigm shift --
trying to make SVN behave like another SCC system isn't good for anyone.
At the time we also faced the "good" version problem. My solution was to
specify that each project-level folder maintain a "last-known-good"
property, that had the revision of the last "good" version. So, for
example, if "foo" was a project, and it has a "last-known-good" value of
45, then rev45 of this project is the "declared good" revision. All that
happened was the test team would work on validating a revision, and then
declare it as good by updating the property+commit.
Since the properties were revisioned, examining the log let us find (a)
which revs were "good", (b) the dates they were created and (c) when the
test team declared them as good. I ended up with a script that migrated
the info into a chart -- very useful. And, of course, this was all
per-project within one repository.
> I've setup Subversion (utilizing Apache on Windows) for my company and
> started adding repositories. I've set things up so that each
> department has a directory, with repositories (projects) setup beneath
> that. Everything was going great, until someone requested a bunch of
> sub-directories with the repositories being buried within that
> directory structure, not at the top level. That brought on a few
> Can you even do that using Subversion? I cannot seem to find a way to
> configure Apache to allow it.
> These users are former CVS and PVCS users, so they are used to
> revision numbers on a per archive basis. They fear making the
> repository at the top level and having several projects beneath that
> will lead to a huge revision number and make it impossible to rollback
> to a specific "good" version of the code should something go wrong.
> How do you mitigated that risk? I would assume by using tags? Any
> other ideas?
Received on Mon Apr 4 22:16:43 2005