In-place editing, version control - what's your solution?

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.

Answer 2

You need to realize that SVN repositories are free. You can create as many as you want.

You also need to realize that you don't have to check out a whole repository. You said:

It also doesn't seem reasonable to have a working copy of the repository wherever there are files to put under SVN control

I'm not sure what you're really trying to do, but I'm under the impression that you use SVN in a peculiar way.

Answer 3

Modern distributed version control systems like Git, Mercurial or Bazaar are the best tool in a situation like this. Not because of the distributed aspect (which is clearly not crucial here), but because it is extremely easy to create a repository in-place.

In Mercurial you just have to do:

cd ~/directory
hg init

With Git is is similar:

cd ~/directory
git init
git add .

Every working copy is a complete repository, and you can push it to remote server as a backup if you like. Moreover all the repository data is stored in a single hidden directory, so you avoid the issue of having tons of .svn directories all around the place.

I use Mercurial to manage /etc on my servers and I find it extremely convenient. One thing to note, it will not mark your file read-only (like RCS), but I consider this an advantage.

Answer 4

As said before you are trying to use SVN for something that should be using a DVCS like git or Mercurial.

Everyone can have their own repository, and then sync it with the mais central repo (like the SVN repo).

This is actually what I use in my own projects.

The only thing I didn't get is why you need locks. A file doesn't have to be read-only. You are probably thinking that way because of the way SVN does merges (you almost always have to do it by hand). Git really does magic[1] and the majority of merges goes without human intervention.

[1] Ok, it's not magic. While SVN cares about files, Git cares about chunks of code. This way it can merge a file changed twice at the same time, as long as you don't change exactly the same chunk of code.