John, it appears there's no consensus on this approach being a good
thing. I also had concerns about it, the same as Greg's and Mike's,
but I didn't take the time to formulate them before reviewing the
patch itself (this was partly because I felt the review would be
useful w.r.t. future patches anyway -- but I should have been clearer
about what was going on, my apologies).
Unless there's something genuinely new to say in the discussion, I
think the best thing is probably to accept disagreement on this
(rather minor) issue, and accept that the patch is unlikely to be
incorporated. It certainly wouldn't be the first unapplied floating
around.
There are plenty of other bugs & enhancements that are not as
controversial, though. Maybe try one of them instead?
Just trying to shunt this thread's energy in a direction that can lead
to a useful result...
-Karl
"C. Michael Pilato" <cmpilato@collab.net> writes:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 24 22:07:59 2003