At Wed, 27 Aug 2014 16:08:14 +0100 =?UTF-8?B?WsOp?= <jose.pas...@gmx.com> wrote:
> > On 08/27/2014 03:53 PM, Les Mikesell wrote: > > It's not that you can't use it, just that it can't protect you from > > the things that can happen through direct file system access. Like > > accidentally deleting the whole repo or changing ownership or > > permissions. > > I don't see your point. There's also a likelihood that those accidents > can happen on a remote server. With a 'server' one can set the permissions such that no one but the server user (or root) can mess with the files, by making the files owned by a dedicated UID which is the UID that the server process runs under, so only the server process can access the files in the repo. If this user's shell is /bin/nologin it becomes impossible to gain a shell process running as this effective user. (Yes, root can still mess with things, but if a rogue user gains root access, you have bigger problems. Presumably a legit system admin knows not to use random direct file system tools on the repo files.) With file://, anybody who can do svn commit to file://..., can *also* use any of the standard file system tools (eg rm, mv, etc.) to mess with the files in the repo. And there really isn't any need for a 'remote server'. Note: there are two meanings for the term 'server': 1) A dedicated computer (typically headless) that is used to provide various network services to other computers on a network (LAN or WAN). 2) A *process* running on any computer that provides services to either other processes on that computer and/or to other computers on a network (LAN or WAN). I don't believe the people avocating against the use of file:// are specificly suggesting a server meaning definitation 1, but are most likely suggesting a server meaning definitation 2, which *could* be on a server meaning definitation 1, but does not have to be -- any Linux desktop can run server processes (as in meaning 2), including Apache (eg http:// or https://) or svnserver (svn:// or ssh+svn://). (I believe it is also easy to set up server processes on (desktop) Macs and I believe it is even possible to set up server processes on MS-Windows *desktop* machines as well.) > > But regarding my question, if file:// is not intended to be used, as you > and Stefan Sperling argued, then what are the available options for > those who need a version control system and can't set up a server? Is > it even possible to deploy subversion in that scenario? > > Zé > > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
