Russell's "one possible way" above basically describes the preferred method to use for this sort of CVS repository surgery. (Well, my preferred method anyway; I think most people's.) I am not aware of any good reason break version history by simply moving repostory files from one place to another, rather than by first copying them then cvs removing them from their old locations in the normal fashion.

And to be blunt, anyone directly screwing with the CVS repository should know these things.

Fortunately, sounds like nothing irreversible was done! If people want it to be fixed, it can be fixed, the repository files can simply be copied (not moved) back to their old location, and cvs rm'd there.

Now, the modules file, that does sound trickier, and I've never used one myself so I don't have much useful to say. You really can't version it and tag it, or something like that? That is yet another serious CVS mis-feature then.

Also, "No direct manipulation of CVS repository without a TIP" seems sort of silly and overly bureaucratic. However much we wish it wasn't so, there are things CVS just plain doesn't let you do any other way - there can be good reasons for a maintainer to directly manipulate files in the repository. Not regularly, probably never even often, but I've done it myself often enough times in the past, at work and etc...

I had this exact conversation with Mark Aufflick yesterday - I don't think the "pre-beta" status of svn is really an issue for stability and repository safety (svn FAQ, some deployed sites). The problem is that they don't issue binaries and they're not guaranteeing client/server interoperability over more than a (3-week or so) release cycle, so everyone who currently works on OACS through CVS rather than release tarballs would need to start building svn client software and keeping it in sync with what is being run on the OACS repository. It's doable, and probably not that much of a problem for the companies and individuals who are the core of OACS development, but it places a burden on newcomers and casual developers that could well drive them off.

which sucks, because CVS blows goats and subversion fixes the bits that suck while keeping the familiar CVS UI...

If there's any interest in following this sort of path I'll find out what the actual (rather than "supported") level of compatibility is between cross-version clients and servers...

Malte,

I've brought up this issue with the other OCT members. I am preparing documents, migration path, and a TIP for OpenACS to switch to using the GNU Arch SCM to replace CVS.

It is simple, has very advanced features for distributed repositories and merging, makes is much easier to maintain an OpenACS repository with your changes while still being able to synch with the main repository, etc.

Talli and Ben Bytheway are the ones who introduced me to it. I've been using it and it is great.

-Roberto