In-place editing, versioning - what's the solution?
I use SVN for development tasks, but still have a lot of files managed with RCS because it doesn't seem sensible to edit them in my private working copy of the SVN repository (as they are often just config files that are also best tested in place) ... It also doesn't seem sensible to have a working copy of the repository wherever there are files to manage under SVN, so I just use RCS.
What is your approach to managing files that should ideally not be moved / edited and tested in place?
More precisely: I would like to have an equivalent
- a write-protected .txt file
- 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 write the change, add a comment, and make it read-only
- Other users should also be able to do this in the same place.
- but the version info should go to a safe place (presumably svn rep), on another server
source to share
I use copy on CoW filesystems such as Ext3cow (disclaimer, I'm one of its authors) to manage a lot of things. For example:
- Using snapshots to rollback all repositories, no matter what type. For example, if I messed up the git tree completely, I can cp -dpfR./@123456789./, which replaces my working repo with files just as they were in era 123456789.
- Using versions / snapshots as native immutable VCS, perfect for / etc and other things. Since files in the past cannot be deleted or changed, each snapshot is an unchanged version of one file or the entire tree over time.
Typically I use git or Mercurial over Subversion because I prefer a distributed VCS, but now I insist on keeping my repositories locally on the local version machine.
For Windows users, I believe there are several portable implementations done entirely in python ... but not really sure.
source to share
As said, you are trying to use SVN for something that DVCS should use, like git or Mercurial.
Everyone can have their own repository and then sync with a central mais repo (like an SVN repo).
This is actually what I use in my projects.
The only thing I didn't understand is why you need locks. The file should not be read-only. You probably think so because SVN is merged (you almost always have to do it manually). git does the magic [1], and most merges are done without human intervention.
[1] Okay, this is not magic. While SVN takes care of the files, git takes care of the chunks of code. Thus, it can merge a file modified twice at the same time, as long as you don't change the exact same piece of code.
source to share
Modern version control systems like Git, Mercurial, or Bazaar are the best tool for this situation. Not because of the distributed aspect (which is clearly not important here), but because it is very easy to create a repository in place.
In Mercurial, you just need to do:
cd ~/directory
hg init
With Git is, the same is true:
cd ~/directory
git init
git add .
Each working copy is a complete repository, and you can push it to the remote server as a backup if you like. Plus, all of the repository data is kept in one hidden directory, so you avoid the problem of having tons of directories .svn
all over the place.
I use Mercurial for management /etc
on my servers and I find it extremely convenient. It should be noted that it will not mark your file as read-only (like RCS), but I consider it an advantage.
source to share
You need to understand that SVN repositories are free. You can create as many as you like.
You also need to understand that you don't need to checkout the entire repository. You said:
It also doesn't seem sensible to have a working copy of the repository wherever there are files for SVN Management
I'm not sure what you are really trying to do, but I am under the impression that you are using SVN in an unusual way.
source to share