On Fri, Feb 29, 2008 at 12:09 PM, Rush Manbert <rush_at_manbert.com> wrote:
> Andreas Benzler wrote:
> > Hello subversion users
> >
> > I have a problem that maybe some others have encountered in the past
> before.
> >
> > We have here a simulation lab with several pc's. On each machine (linux)
> is the same repository checked out with the same username. Password storing
> is enabled, so users do not enter a password when updating the working copy.
> The most time we develop software for this lab in our office where each user
> commits changes with his user name on his pc. When it comes to integration
> and testing in the lab we do a lot of additions of code in the lab on some
> of the pc's and we have to update all others with an svn update. So far so
> good. The problem is, that all commits done in the lab are done with the
> user the repo was checked out with and no one can realy figure out who made
> which changes. I would like to be able to do updates with the user that
> checked out the repo without entering any password and get asked by
> subversion at a commit for a user and password.
> > What I tried so far was that I gave this lab checkout user only read
> access to the repo and all others read/write access, enabled password
> storing only during the first checkout so that this single password was
> stored in the auth section of my .subversion folder. Disabled the password
> section afterwards and tried to commit changes. I only get the error that it
> is forbidden for this user, because it tries to use the user which checked
> out the working copy. Is there a way to force the svn client to ask for a
> user name when commiting and still can do svn updates with the lab user
> without entering any passwords? Maybe a wrapper script around svn? Or is
> there any internal configuration settings I can use?
> >
> > On my local machine I am using subversion 1.4
> > On the server is currently a 1.3.2 installed
> >
> > Thanks for any hints and tips.
> >
> > Andreas Benzler
>
> Maybe a dumb approach, but I'll throw it out there anyway.
>
> On your lab PCs, you could install scripts named svn.bat and arrange
> things so that they are found earlier in the path than your real
> svn.exe. The purpose of the script files is to examine the subversion
> command and either pass the whole thing through to the real svn.exe, or
> (in the case where the subversion command is a commit) check for a
> username and ask for one if necessary, then pass the modified command
> through to the real svn.exe.
>
> This only works for command line svn, so if your lab PC users commit
> with TortoiseSVN or some other GUI client, you're out of luck. I guess
> you could put in a start-commit hook that looked for the lab PC username
> and aborted the commit if it was seen. But that won't educate your users
> about the need to specify a username, because I don't think you can
> display an error message in a hook script.
>
> - Rush
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
This is almost exactly the approach I implemented in almost the same
situation. I renamed the svn client to svn-real, then put a shell script in
it's place. It looked to see whether it was a commit operation, if so it
would prompt the user for a username and then use the '--username' to pass
it on to the svn client. Otherwise it just passed everything on to the real
thing.
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
Received on 2008-03-01 08:33:23 CET