> -----Original Message-----
> From: John Peacock [mailto:john.peacock_at_havurah-software.org]
> Sent: May 2, 2008 2:20 PM
> To: Scott Palmer
> Cc: users_at_subversion.tigris.org
> Subject: Re: svnserve authenticating against Windows domain
credentials
>
> Scott Palmer wrote:
> > I don't want webdav. I don't need it and have no use for it.
>
> I meant the Apache server.
>
> > Of course I also don't understand how step 2 requires it. I don't
> have
> > to do a recursive checkout to change the properties on a folder.
>
> You don't need it to perform step 2, but you would need it if you went
> this route.
>
> > "Can't" was maybe too strong a word. It's just not all that simple.
>
> It's also much easier than you probably realize. You don't need to
> create tags, etc, you only need to change the URL from svn:// to
> http://
> (assuming the rest of the URL is the same). It would be not all that
> difficult to write something to walk the repository and update the
> svn:externals properties, pegged revisions and all.
There is more to change than the url protocol.
Consider that if I leave the pinned revision in place, the url,
regardless of the protocol used in the HEAD revision, is referring to
place in the repository from a point in time BEFORE I changed the
protocol of the URLs. Any pinned branch that has svn:external
references within it will be broken.
> > I don't know how strongly I have to say it... I DON'T WANT A WEB
> SERVER,
> > Seriously.
> > A full-featured web server is simply superfluous.
>
> Except for the part where it works with Windows *now*, without any
> difficulty.
See above for an example of the difficulty involved in switching access
methods.
If it was a simple change I would consider the extra burden of dealing
with Apache in addition to subversion.
> I think you may have some misconceptions
> about Apache with regards to Subversion. There is no reason to
> consider
> Subversion over Apache as anything other than a different way to
access
> the repo (i.e. it isn't a full featured web server, but merely a
> service
> that happens to use http as the transport method)...
From the ABOUT_APACHE.TXT file that was installed in the httpd
subdirectory of my Subversion Server install:
"The Apache Project is a collaborative software development effort aimed
at creating a robust, commercial-grade, featureful, and freely-available
source code implementation of an HTTP (Web) server."
You can use a sledge hammer to make lemonaid. But it isn't the best
way.
I would like to keep things as simple as possible. A commercial-grade,
full-featured web server is a relatively complex bit of software to bolt
on to Subversion, just so it can use an alternate transport mechanism
that I wouldn't need if the Windows port of svnserve was integrated into
the Windows environment. Granted the reality is that svnserve is not
fully integrated into the Windows environment, so if I want my
authorization to work better I will need to go to an alternative like
Apache. At that point my aversion to Apache is more of a philosphical
thing. But if that is what it takes to get proper logins working on
Windows I can guess how the vote will go. The team will elect to stick
with svnserve and no real authorization. They will be scared of
mistakes during the reworking of all the URLs. svnserve has worked fine
so far, Apache is something new (in our context), etc.
Just for the sake of experiment, is there a quick and plainless example
of how to set up Apache to do the domain login via LDAP and Active
Directory handy? (Assuming I want to figure it out myself rather than
go with VisualSVN Server.)
Regards,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-02 21:18:29 CEST