On the server box I have always just used file but I have never tried
to do a commit from there before. From the remotes
obviously we can't do that so we are already using svn protocol and I
know for a fact that the svnserve process is already set up and runs
under xinetd. I agree this is a better solution.... just haven't
thought about svn admin for a while, proof that it's a good tool. I
control the box so I will take care of it. Thanks...
On Wed, 2006-11-01 at 19:25 -0600, Ryan Schmidt wrote:
> On Nov 1, 2006, at 18:47, Colleen Dick wrote:
>
> > I have several team members. We are elaborating a web application.
> > Each developer has their own private deployment and we
> > all commit to the repository from our remote machines just fine.
> > Recently I needed to do several emergency tweaks on the
> > working copy that is the live online copy. I would like to commit
> > these tweaks to the repository (which by the way lives on the same
> > physical machine as the live online deployment) When I try to commit
> > I get
> > svn: Commit failed (details follow):
> > svn: Can't create directory
> > '/back2/svn/tixrus/db/transactions/674-1.txn': Permission denied
> >
> > svn is owned by the svn user and so is the directory tixrus
> > I guess when people commit remotely they go in as that.
> > Should I become the svn user whenever I commit to the repository that
> > is on the same box? I can do that. I don't want to chown anything
> > because I'm afraid I'll lock all my developers out.
>
> How are you accessing the repository? Via the file:/// protocol? If
> so, I encourage you to investigate setting up an svnserve process and
> using only the svn:// protocol to access the repository. You will
> avoid permissions problems like this (because only a single user --
> the user under which svnserve runs -- will need to access the files)
> and you will increase security by ensuring that only this user is
> able to access the repository. See the book at http://svnbook.org/
> for instructions on setting up svnserve.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 2 18:13:25 2006