# firstname.lastname@example.org / 2003-08-19 11:00:30 -0500:
> Roman Neuhauser <email@example.com> writes:
> > # firstname.lastname@example.org / 2003-08-19 14:06:04 +0200:
> > > I don't know what to think about this: we're in rev 18, and the number
> > > of times I had to run svnadmin recover is about the same. I'm not sure
> > > if this is a Subversion or FreeBSD issue, so I'm cc'ing the port
> > > maintainer.
> > the problem turned out to be wrong umask: subversion/bdb creates
> > log files ($REPOS/db/log.*) with 644. This makes a pretty poor
> > comparison to CVS: Subversion can't cater for three users without
> > hacking. (The handwaving in the handbook notwithstanding.)
> You're kidding, right?
> Ask Karl about how often this happens in CVS repositories. Answer:
> ALL the time.
my answer: I have never encountered messed up RCS file permissions
in any CVS repository I've been using, be the access method pserver
or ext/ssh. granted, I'm not a CVS old hand: just three years or so.
> When three cvs users all start modifying repository RCS
> files, the most *common* problems is messed up permissions and/or
so umask 022 is messed up?
unless, of course, you are talking about messing with the RCS files
directly, but that doesn't qualify: we're not messing with the SVN
repository database either. just svn+ssh://
This is what the svnbook says:
"The most common problem administrators run into is repository
ownership and permissions. Does every process (or user) in the
previous list have the rights to read and write the Berkeley DB
files? Assuming you have a Unix-like operating system, a
straightforward approach might be to place every potential
repository user into a new svn group, and make the repository wholly
owned by that group. But even that's not enough, because a process
may write to the database files using an unfriendly umask--one which
prevents access by other users."
The surrounding text makes it seem like it's talking about
mixed-access repositories, ones that are accessed with file://,
svn+ssh://, and through webdav, but in fact, it's not.
The From: header's been munged to get rid of unwanted cc's.
My real address: email@example.com.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Aug 20 15:20:01 2003