You don't need to maintain a checked out tree; just publish the
repository url, the same one you use for Subversion clients! Point
your browser to http://svn.collab.net/repos/svn/ for an example.
(Have you read the Handbook, btw? Some of these questions may be
answered there.).
-K
Will Holcomb <will@himinbi.org> writes:
> Hi, I run a web server for a university and am working on an online
> portfolio project and I have been looking at webdav and subversion as
> possibilities in the stuff I am working on and wanted to ask some questions
> and see if I could get some feedback on the sorts of things I am
> considering doing as to whether they are possible and a good idea.
>
> On the webserving, I have had the entire web repository in cvs for about
> a year now. There are a lots of different pages managed by lots of
> different people and it was really useful to have the traceability and fine
> grained revision control that cvs offered. (The down side was a complete
> duplication of the web hierarchy and a variety of geek oriented
> interfaces (as well as cvs's usual problems.)) I've been watching
> subversion for a while and I am glad to see you reach alpha. It is looking
> good.
>
> I have been trying to come up with a way to have requests be transparently
> mapped to the subversion repository so that I don't have to maintain a
> separate checked out version for the webservers use. Not sure if I can
> manage it (going to play with mod_rewrite), but if I could, will this have
> any adverse affects on the repository? (being read accessed with the
> frequency of a medium traffic webserver)
>
> Oh, while I am on it. The webserver process has to have write access to
> the repository regardless of whether it is writing or not? Well, that's
> not really a question since I have verified that... Is there any way to
> avoid this? With cvs I had a separate locks directory that the webserver
> user could write to, but the main repository was restricted. It meant that
> an attacker could screw with the locks and blow the webserver's quota, but
> the repository as a whole was safe. Is this sort of workaround possible
> with subversion?
>
> The other questions I have surround a project I am working on for the
> education department here. They have to be able that they are teaching
> well, so they are getting the students work online and setting up an
> online portfolio where it can be discussed. I thought that it would be
> really handy if I made the file system stuff wedav based. That way they
> could make changes and what not and I wouldn't have to worry about issues
> that arise when there is only one copy. (Changes made after a review.
> Changes made as part of a later assignment that change the nature of the
> project. Etc.) It also makes it more widely accessible as deltaV compliant
> clients become available.
>
> The thing is that they will all be creating a couple hundred megs worth of
> stuff (education majors make movies and power point slides and all
> sorts of interesting things nowadays) and over time that will have to be
> archived and moved away.
>
> If I have a single repository then there is no way for me to remove a tree
> completely, is there? From what I was reading of how the trees and deltas
> and what-not are stored it seems like it would be hard. The other option I
> have is lots of individual repositories, but there is no way to
> dynamically add them to the server is there? I would have to create really
> big apache config files and reload the server (there are 5-600 users at a
> time here). It would make creating dynamic adding of users impossible it
> seems. (Well, cumbersome at least.)
>
> Any suggestions would be much appreciated. Congratulations again on the
> good work.
>
> Will Holcomb
>
> P.S. I'm not on the list, so please cc in any replies.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 1 18:36:17 2002