[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: pre-checkout/export hook

From: Janulewicz, Matthew <MJanulewicz_at_westernasset.com>
Date: 2005-10-19 19:03:05 CEST

Sometimes answers need re-iterating. This isn't a hostile mailing list.
Take it easy.

Personally, I don't go out and do anything the first responder to a
question on this list, or any list, gives me. I'd rather have a quorum.
The more the merrier.

I think the subtle, underlying point is that there is already one widely
accepted and used solution to this problem, another good solution
forthcoming (any day now if you read the dev list) and any other
solutions proposed are a little hacky. As many of us have experienced,
the devs and users aren't going to (nor are they able to) custom fit a
solution to every little, odd, different environment that people have.

Personally, 'We can't install Apache' isn't a good enough answer for me,
either. Why would an SCM practitioner not have acces to their own
machine to set it up in a sensible way, to perform his or her job?
Company policy? Bah! Change it. Half my job is evangelism, it should be
yours, too.

Calling someone out for a 'me too' response on this list isn't cool and
doesn't contribute anything.


-----Original Message-----
From: Gale, David [mailto:David.Gale@Hypertherm.com]
Sent: Wednesday, October 19, 2005 9:44 AM
To: John Peacock; Eric Clark
Cc: Marcus Rueckert; SVN Users Mailing List; SVN Dev Mailing List
Subject: RE: Re: pre-checkout/export hook

John Peacock wrote:
> Eric Clark wrote:
>> Apache with mod_authz_svn would work if we were using apache, but we
>> are not. And we cannot put an http server on the machine that the
>> repository resides on. We are using ssh and there is no other option
>> to this. We really need a pre-checkout/pre-export hook. What do I
>> need to do to get these hooks implemented because I do not see any
>> other option for us? Thank you for your response Marcus --
> As Marcus said:
> > svnserve as it will be in 1.3.
> It's really very easy to use svnserve with ssh in tunnel mode to
> restrict access to the repository to a single user id, yet use
> separate ssh keys for each user, see:
> http://svnbook.red-bean.com/en/1.1/ch06s03.html#svn-ch-6-sect-3.5
> And now that svnserve will includes authz support, you can limit
> access without the use of hooks.
> John

That's got to be one of the most annoyingly useless answers I've seen,
and I'm not even the guy with the question!

Eric is looking for a solution for _now_, today, not some point in the
future when 1.3 is released. Marcus's answer (authz through apache, or
wait for 1.3) didn't fulfill his needs, so he asked for anyone who had a
more immediate solution; your response was to simply parrot back the
answer that he'd already received, and determined to be inadequate!
This would be acceptable if he'd simply missed something in Marcus's
reply, and you were drawing his attention to the pertinent information;
however, that's simply not the case.

And to Eric: would it be possible to separate the sensitive information
out into a separate repository, and restricting access to that?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

E-mail sent through the Internet is not secure. Western Asset therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Western Asset therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 19 19:06:16 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.