On Thu, Jul 17, 2014 at 09:27:13PM -0500, Adam Thompson wrote: > I'm looking for a distributed VC system where even remote clients with > full(?) write access cannot, or at least would find it fairly difficult to, > alter history?
> svn - definitely possible (AFAIK) to change the past. With remote clients, Subversion is definitely safe. To modify the original repository's history, you need access to the SVN server host and svnadmin dump/load with svndumpfilter. http://subversion.apache.org/faq.html#removal > bzr - unknown The bzr project is dead. https://www.stationary-traveller.eu/pages/bzr-a-retrospective.html I would advise against using bzr for new projects. > hg - unknown I'm not sure. This page has some info: http://mercurial.selenic.com/wiki/ChangesetEvolution "Mercurial will actively prevent you from rewriting parts of history which are not safe to rewrite" sounds ok. I would refrain from using experimental extensions, though. > git - unknown Disable forced pushes to the git server and remote clients shouldn't be able to rewrite history. Set receive.denyDeletes, receive.denyNonFastForwards with git-config(1). receive.denyDeleteCurrent and receive.denyCurrentBranch or only needed if your server repository isn't bare (which is unusual). > everything else - unknown. > > For this application, a file-oriented system would be preferred over a > snapshot-oriented system like git. Most modern systems are snapshot-based. As far as I can tell, RCS and CVS are the only file-based systems on your list. The rcs(1) implementation in OpenBSD is OpenRCS, a rewrite of the original. RCS requires write access to ,v files, so it's definitely possible to alter history by editing ,v files. However, you could monitor these files for undesired changes (e.g. by using changelist(5)). > I'm trying to combine (soft) WORM-like properties with the benefits of a > version control system. Does not need to be utterly secure, merely needs to > be "good enough" to deter both script-kiddie level attackers and inebriated > sysadmins. What kind of data is this system going to manage? Data in /etc? Something else? > CVS would be ideal except that access control is AFAIK basically ternary > (none,read,write). And what are your requiments for access control exactly? Subversion has path-based access control that cannot generally be emulated by distributed systems. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html With Subversion 1.8 from ports you can use in-repos access rule storage: http://subversion.apache.org/docs/release-notes/1.8.html#in-repo-authz Just make sure not to give your users file:// based repository access.
