Gerhard wrote regarding 'Re: [EE] Backup of live repositories' on Mon, Jan 30 at 16:26:
> Danny Sauer wrote:
> 
> > SVN commits are atomic. :)
> 
> Maybe you didn't read my message, and in any case you seem to have
> missed the full meaning of "logical set of files". I'd like to see
> how you do an atomic commit for (I'm citing from my previous
> message) "a change that

Yup, I skimmed over that, mostly just making the assumption that the
singular word "commit" in the context of backing up a version control
system meant a sngle commit, not a whole bunch of commits over a
period of weeks. :) No version control system replaces proper project
management.  Which is probably what you said in the part I skimmed
over.  :)

> > For someone who's really concerned about that, they should be
> > using a storage scheme which supports snapshots.  
> 
> Yes, like WinXP/2003, among others (see also below :)

It's not really relevant to the repository backing up context here,
but the Windows shadow copy service doesn't handle the page file
(which doesn't really matter) and doesn't make a snapshot of the
system volume information.  Not that someone would want to repartition
their disk or change the volume name while they're in the middle of
backing up from a snapshot, but if they did, it'd screw up the restore
(because the backup would have data from one partiton size and volume
information from the changed volume).  For some reason, MS apparently
feels compelled to screw up *something* just for the sake of screwing
up...  The shadow copy services thing really is kinda neat, though,
for what it's designed to do.

> > 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.  
> 
> Interrupted by what? Having a repository server running on a machine
> without UPS and some kind of RAID is almost negligent :)  I run only
> a really small-time operation on my server, but it's been a looong
> time (can't even remember) that anything broke down this way.

System crash, possibly due to heat buildup or a sloppy programmer
running privledged code?  Someone tripping over the machine's power
cord?  A new service pack? ;)  A band of raiders, ransacking the
wiring closet?  You never expect the Spanish Inquisition...

> But yes, you have a point: this is definitely one of the areas where
> SVN has an advantage over CVS. OTOH, the next major release of CVSNT
> will pretty much get rid of much of the old CVS code base and the
> RCS files and use a database backend, which probably will address
> some of these issues, too. But that remains still to be seen... also
> when this will become stable enough.

Yeah, I suppose I should have said that the journalling is provided by
bdb - I'm not sure if it handles the directory-based backend the same
way or not.  I've never felt compelled to use the directory backend.
:)

> > Specifically What's New in Subversion 1.2 - Optional locking
> > ("reserved checkouts") 1.2 was released in August of '05
> 
> Hm... There's a bit more to it than just a lock command. How about:
> - Enforcing the requesting of a lock before allowing edits (that is,
> enforcing read-only checkouts)? You know, developers are lazy, and
> there's a huge attraction in just not thinking about having to lock
> a file...  - Locking per branch? Doesn't do me much good if a file
> is locked all over.  Say the developer works on the development
> branch on a picture, and I want to commit the final test code to the
> production branch (including that file that's locked on another
> branch by the developer).

SVN uses the DAV protocol for locking, basically the protocol that
Windows' "web folders" are based on.  Web-DAV supports the "other
developers don't have to do anything" kind of locking on a per-file
basis.  Depending on the client, some or all of that may well be
automated.  As far as per-branch locking, branches are really separate
copies in SVN.  Since they're implemented as essentially seperate
repositories whose only relationship is determined by the developers,
if you lock a file in one branch, the other branches are unaffected.

> > 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,
> 
> Ah, interesting. Why do they say in the svn-book (1.1) that there
> are no ACLs then? Seems to me that a hint to that possibility would
> be quite helpful :)

The "ACLs" really weren't implemenetd in SVN at the 1.1 stage, those
were implemented in 1.2 for the Apache module and 1.3 for the
standalone server, AFAIK.  You could use Apache to restrict access,
though, based on the commands which were sent.  I'm not sure if that
was documented or how I ended up knowing that, but that was critical
to me providing the ability for unauthenticated users to get read-only
access to specific parts of the trees.

> Well, I'd say you can't really talk about the "CVS family" if you
> don't know CVSNT; the difference in the details and features is
> huge. Start here: http://cvsnt.org/wiki, then here
> http://www.cvsnt.org/manual/

Eh, SVN came along so I stopped following CVS development. :)  The 'nt
version looks pretty cool, though.

> > as it just seems insane to host something important on Win32. ;)  
> 
> Not sure why you would say that. A well-maintained Win server can
> run well, and a crappily set up and maintained Linux box can be a
> hazard. For me, it's mainly a question of the level of knowledge and
> diligence of the admin. 

Well, for one thing I'm a Linux zealot, 'cause that's what pays the
bills. :)  But mainly I put the winkie smilie at the end as a note
that I'm largely joking.  I do rather question the merits of a
"server" OS which runs a full-blown GUI with an integrated web browser
whether you want it or not, but in the end I'll agree with you (since
I've done stable Win32 servers before, too).  A properly administered
Win32 box (post Win2K) can work just fine, and an improperly admin'd
*nix box can be a POS.  The Windows shell does suck royally, though
(despite recent improvements), and they should stop saying they're
POSIX-compliant when so many POSIX-y things just don't map properly.
:)

> > I've always used file system permissions to control CVS, which
> > works reasonably well but is far from convenient
> 
> Still possible, but I prefer the CVSNT ACLs. One detail: If you want
> to hide a module using file permissions, you usually get a message
> "Directory ... not available" or something. Not really the way to
> /hide/ something :) Doesn't happen with CVSNT ACLs; it's all gone if
> you don't have read access.

Amusingly, that was one of the big draws to SVN - I could make things
just dissapear if I wanted to [apply adequate Apache wizzardry].

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