John Peacock <jpeacock@rowman.com> writes:
> C. Michael Pilato wrote:
>
> > We provide sensible defaults already. We promise to create our files
> > and directories in exactly the same way that every other program you
> > use creates files and directories -- as the user/group that runs the
> > file-creating program. No surprises there. What's not sensible about
> > that?
>
> Because the only time that this is _sufficient_ is when the repository
> is private to the user creating it. For all other [shared] access,
> more work is required. You are arguing that documentation is
> sufficient; I am arguing that we can provide the necessary
> configuration without difficulty, so why don't we.
Because it isn't without difficulty. It comes at the cost of
maintainance. You've modified our configure stuffs to look for
Unix-specific interfaces. You've modified our code to do
Unix-specific things. And actually, instead of helping to solidify
the process of setting up repositories, you've now duplicated efforts
-- people can either use these new flags, or they can do things the
old way, with no difference in behavior.
> Let me turn this around: a year from now, Subversion is now supporting
> other database backends. Are you advocating that we provide only
> general schema documentation and refer to the DB docs for actual
> commands? Or do you think that we should provide sample scripts to
> create the tables/user objects with our supported DB's? Are you going
> to say that any system administrator who wants to run Subversion over
> PostgreSQL needs to manually set up the database schema and user
> rights within that database?
I can't really answer this because I don't fully grok what would be
needed for such a database backend abstraction. Today, users don't
have to think about database schemas at all, but I don't know enough
about more complex databases to say whether or not that trend can
continue into the future.
> That's what I view this patch to be analogous to; anyone wanting to
> run BDB in a shared mode must perform some additional steps after the
> area has been created. I just think it makes more sense to do that on
> behalf of the administrator instead of relying on their knowledge of
> shared file security.
But unless I'm completely off-base, there will *still* be additional
steps that need to be taken. As is pointed out by Chapter 5, both the
'svn' and 'svnserve' programs need to be wrapped in scripts that do
umask()y things if you expect to really use them for shared access.
You have to be careful 'svnadmin recover' (or 'db_recover'). And who
knows how many other things can basically make the work that your
patch is doing completely pointless. So, you've removed one step that
*some* people on a *particular* set of OSes *might* have to take,
depending on their access patterns, and those people are *still* the
ones most likely to run into problems.
So, unless you can make a repository preserve the --owner and --group
settings throughout its entire lifetime, gracefully recovering from
the many situations which could cause the actual permissions to
deviate from what a user is going to expect them to be forever
(because, hey, after all, they already told Subversion what the owner
and group should be, by golly), I think this patch is bogus.
> > 'svnadmin create' + 'chown' just isn't really that tough to pull
> > off. :-)
>
> If I might point out that the Book doesn't even currently mention
> chmod/chown. It is incredibly vague on the details:
>
> http://svnbook.red-bean.com/html-chunk/ch05s05.html
>
> You know it's easy, and I know it's easy (now), but there is no
> documentation of any depth.
Fine. I hear it. Heck, I wrote that chapter, so I'll even take the
blame for it. And I'm all for fixing it. But that doesn't change my
thoughts on the remainder of your patch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 24 21:52:16 2003