Question

I am using SVN for development tasks, but still have many files managed with RCS, because it does not seem reasonable to edit them in my private SVN repository working copy (since they’re often just configuration files that are also best tested in-place). It also doesn’t seem reasonable to have a working copy of the repository wherever there are files to put under SVN control, so I just use RCS instead.

What is your approach for managing files that should ideally not be moved around / are edited and tested in-place?

To be more precise: I’d like to have the equivalent of

• having a write-protected file.txt
• a command like ‘co -l file.txt’ (RCS) to make it editable
• the ability to edit it in place and test it immediately
• a command like ‘ci -u file.txt’ (RCS) to record the change, add a comment and make it read-only again
• other users should also be able to do this in the same place
• but, the version info should go to a safe place (the svn rep presumably), on a different server

Answer 1

I use copy on write file systems (CoW) such as Ext3cow (disclaimer, I’m one of its contributors) to manage a lot of stuff. For instance:

• Using snapshots to roll back entire repositories, no matter what kind. For instance, if I completely screw up a git tree, I can cp -dpfR ./@123456789 ./ , which replaces my working repo with files just as they were at epoch 123456789.
• Using versioning/snapshots as its own immutable VCS, ideal for /etc and other things. As files in the past can not be deleted or modified, each snapshot is an immutable revision of a single file or the whole tree in time.

Typically, I use Git or Mercurial over Subversion because I prefer a distributed VCS, but I now insist on keeping my repositories on a versioning FS locally.

For Windows users, I believe that there are some portable implementations of the same done completely in python … but not really sure.