Danny Sauer wrote: >> - 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. :) 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 involves schematic and board changes, component/BOM/purchasing info changes, case drawing changes, firmware changes, PC software changes, production documentation changes, user documentation changes, all done by different people." It doesn't help in this context that a single commit command is atomic; the repository is, from a logical point of view, necessarily in an inconsistent state if any of these elements of the overall change gets committed before any other. But they practically have to -- atomic commit command or not. >> 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. Yes, like WinXP/2003, among others (see also below :) > 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. 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. >> 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 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). > 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 :) > I'm curious how you're doing access control with CVS, actually. I'm > not familiar with cvsNT, 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/ > 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. And there are many people who run CVSNT on Linux and other Unix variants. Don't let the "NT" get in your way -- this is a left-over from the old times when CVSNT was the Windows port of CVS. It's not anymore, for a long time -- it's just (well, not exactly "just") another branch of CVS, and one that's available for a number of host systems. > But really, does cvsNT add some access control features beyond those > offered by vanilla CVS? Yes, a pretty much full-blown ACL system. Using the sspi protocol, it binds right into the WinNT user/group configuration. Start here: http://www.cvsnt.org/manual/html/Security.html > 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. Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist