Michael Sinz wrote:> Molle Bestefich wrote:> > Marcus Rueckert wrote:> > > MOITRY Stéphane wrote:> > > > I vote +1 for a repository enumeration feature to be included in> > > > subversion. It could be a very useful feature especially when a new> > > > developer comes in a team, he could get the sources he needs without> > > > needing to write down the repository names from another computer ...> > >> > > we had a rather long discussion already a few months ago.> > > most people agreed we dont want that overview in general.> >> > That's incorrect.> > You're confusing "most people" with "yourself and 1 or 2 others".> > Well, some of us may have not been very vocal
Fair enough.
Branko Èibej wrote:> As a matter of fact, it was a consensus (or at least a huge majority) of> the SVN committers. Everything may not be in the mail archive, though/
I don't think that's what the mailing archive says. But I'm sure thatyou're more in touch with core developers' feelings on this issue thanI am, so I trust that you're right.
This is not a feature that would be good for Subversion developers, soit's not like it is strange in any way that they would think of it assuperfluous and useless. It's a feature for newbies. It's a featurefor people setting up Subversion. It's a feature for GUI users,mostly. It's not for Subversion developers. It's a feature thatwould sell Subversion to a whole lot of software development companiesthat uses no, and has no prior experience with, any kind of SCMsystem.
But let's drop that whole discussion until someone actually showspatches - then the core developers can decide if you think it lookssane enough to be in the codebase or not?
Michael Sinz wrote:> Molle Bestefich wrote:> > The conclusions, as I remember them, was:> > - It would be a nice feature to have> > - It should be disable-able (disabled by default, even)> > - If implemented, it should be done with security in mind> > - A amount of thought has to go into how it can be done wrt. the> > different protocols that Subversion supports - it might be unfeasible> > to implement for some of them.> > That is an understatement. For example, how would file:// work?
How do you browse a local filesystem looking for folders and folderscontaining repositories? Or?
> And what about svn+ssh?
Since svnserve is pointed to a root directory, that root directorybecomes the root folder of the svn filesystem on the server, so tospeak. svnserve only supports repositories located at this folder orat a folder exactly below the root folder. So it is presented as atwo-level filesystem containing just the root folder, and perhaps anysub-folders with repositories that it might contain. I fail to seethe hard part, feel free to elaborate? Are we talking protocoldifficulties?
> This basically works out as a "nice to have" feature in the HTTP/dav> case until you realize that in that case an HTML file would deal with> the issue nicely without opening up questions of showing/hiding> repositories that you may not have access to. (Not all repositories> are open to the public...)
You're on the wrong track here, but I'm getting tired of pointing this out.And the security side of things are pretty easily fixed (start byturning the feature off).
Brian W. Fitzpatrick wrote:> As I recall, the consensus was that it's a fine feature to have, but> that it doesn't belong in the core Subversion codebase. I'd love to see> a 3rd party script that provides this functionality.
The whole idea of this feature is that it should be basicfunctionality of any SVN client to be able to browse a SVN server,just like it's basic functionality to get server info or browserepositories. I fail to see how a script could solve that?
Received on Fri Apr 22 21:02:56 2005