Greg,
I see your points, it is quite a problem. I would point out, though,
that CVS out of the box handles this, albeit not too much more
gracefully than the umask trick (it does have a CVSUMASK environment
variable which works much like I described one of my options below).
This was one of two issues that was the biggest pain in getting
Subversion running for my team (the first being the relative difficulty
in getting the software running on our server, which is rather old in
terms of packages), and not even because it was technically challenging
to solve. I feel it is important to address, even if the solution for
now is somewhat cheesy (since clearly the right solution is the fix to
BDB that you mentioned below, which we just have to wait on). <warning
type="brainstorm" message="ideas thrown out quickly">Put the answer in
the FAQ for one. Make svnadmin check for bogus situations (seems likes
svnadmin already breaks the abstraction layer, so it is a perfect place)
and have it report out a URL to get more information. When you svnadmin
create, have options right on the tool for setting it up in "group"
mode, have it report out a message on where to get information about
sharing the repository right as the repository is created. When you
install the tool, have it automatically install a svng form of every
command which is the umask trick. </warning>
BTW, I'd be perfectly happy with an option to set the umask at the
repository level with an error message being reported if you ever try to
do it in threaded mode w/ multiple repositories w/ different umasks. It
seems relatively unlikely that anyone would want multiple umasks anyhow.
Even with that hindrance, I'm still really happy to finally move our
team away from CVS, thanks guys for making such a great product.
Nathan
Greg Hudson wrote:
>On Thu, 2004-03-04 at 07:31, Nathan Sharp wrote:
>
>
>>While I agree with you technically, practically I find the solution to
>>be nothing more than a workaround and annoying, complicated by the
>>fact that it has the side-effect that when using rav_local to check
>>stuff out of the repository the created working directory has the
>>bogus group write permissions set. The ideal solution would be to
>>have options in DB_CONFIG which specifies a umask and group ownershipe
>>to use just for the database.
>>
>>
>
>We have some indication that BDB will eventually implement an option
>like this. (It would probably be more like an API option to specify
>that new logfiles should be chmodded to match the permissions of the DB
>file.)
>
>
>> Obviously that is out of your hands, but perhaps there could be a
>>svn option which sets the umask while calling to the DB but leaves it
>>at the original value when working with the working directory.
>>
>>
>
>That wouldn't be thread-safe. (Welcome to Unix sucking.)
>
>
>>Also, while the answer wasn't hard to find on the internet and in your
>>book, it wasn't easy to discover either. A better error message would
>>go a real long way here (and yes I know the error is coming from the
>>DB, which you have little control over).
>>
>>
>
>Yeah, I don't think we have a good way of distinguishing this error from
>other errors.
>
>We have talked about writing code to detect this condition either before
>it happens (to prevent wedging the database) or after it happens (to
>give a better error message when the database has been wedged this
>way). The first option is a bit problematic because it might deny
>access in some legitimate corner cases (e.g. I've made a private copy of
>a repository and want to access it, and don't care that I will be
>screwing up everyone else's access to my private copy), while the second
>option merely requires violating the BDB abstraction barrier a little.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
Received on Fri Mar 5 13:44:41 2004