Gerhard wrote regarding 'Re: [EE] Backup of live repositories' on Sun, Jan 29 at 17:10:
> - Ideally, a commit is an atomic operation on a logical set of files. In
> practice, this is not always the case.

SVN commits are atomic. :)

> Well, yes or no. For whoever is really concerned with that, the suggested
> way would be to stop the server process (or lock out the users), run the
> backup, and restart the server process (or let them back in). This doesn't
> seem to be a problem in most situations. (Which isn't to say that it's
> necessary.) 

For someone who's really concerned about that, they should be using a
storage scheme which supports snapshots.  An LVM volume, for example,
can have a snapshot made which will be a consistant copy of the given
filesystem at the time that the snapshot command is initiated (I'm
pretty sure it's as of that time, but it's never been important to me
as I've only wanted a consistent snapshot more than a specific time's
snapshot).  Then you make a backup of that snapshot volume.  It's
really a wonderful thing for doing stuff like backing up in-use
repositories, and even databases when you can't afford to lock the
tables during a dump.  The drawback is that you need "some" space for
the snapshot, but if your storage is at 100% capacity, you'll be
having bigger problems real soon anyway. ;)

> The exact process of how to re-commit data that has already been committed
> but then lost on the repository side is probably quite different between
> the two,

CVS doesn't use a journaling system - the changes are basicaly
immediately applied to the end of the old RCS file.  So an interrupted
commit can leave files in an inconsistant state, and can be a pain to
clean up.  As far as I recall, SVN gets around that by first writing
the new diff to a journal, then making a copy of the file to be
changed and appending the new diff to the list of diffs.  The updated
file then replaced the old file, and finally the journal is cleared.
If anything happens while the server's getting the diff, then the
change is rejected.  If something happens between the time that the
server gets the diff and the time that the journal is cleared, the
server can replay the journal.  In either case, there is no time
during which the list o' diffs is in an inconsistent state - there are
only times where the new change is not in the list or is in the list.
Cleanup is easy, and automatic in many (most?) cases.

This, BTW, is why journaled filesystems rock - you can stil lose *new*
data (no way to fully prevent that), but the filesystem is never in an
inconsistent state. :)

> Some time ago, I looked into it and the main reasons why I did not switch
> to SVN were that it doesn't permit file locking (which I consider essential
> for working with non-mergeable files) and it doesn't have ACLs. I need both
> features, so that's a no-go right from the start, no matter how convincing
> other features may be.

This is the part I really wanted to reply to.

http://subversion.tigris.org/svn_1.2_releasenotes.html
Specifically 
    What's New in Subversion 1.2 
    - Optional locking ("reserved checkouts")
1.2 was released in August of '05

As far as ACLs, you can indivudally restrict read and write access
down to the individual file level if you're using the Apache module,
which is my preferred method of deploying SVN (since I typically want
to run other web services on the same server, like viewCVS, etc).  As
of SVN 1.3, you can do path-based authorization with svnserve.  It's
new as of Jan 1 this year, but the pre-releases have been going on for
a while, and it's been pretty stable.

I'm curious how you're doing access control with CVS, actually.  I'm
not familiar with cvsNT, as it just seems insane to host something
important on Win32. ;)  But really, does cvsNT add some access control
features beyond those offered by vanilla CVS?  I've always used file
system permissions to control CVS, which works reasonably well but is
far from convenient - SVN's ability to use Apache LIMIT blocks was a
lot nicer, IMHO, mostly since I could use arbitrary LDAP attributes
for access control.

--Danny
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist