In a message dated: 11 Sep 2003 08:12:24 CDT
Ben Collins-Sussman said:
>It's probably far easier for a sysadmin to just
>post a single HTML document on the intranet that lists all project
>repositories. It's not like running 'svn list-repos' is so much more
>convenient than looking at a web page.
Another option would be for the admin to keep a central repo which
contains a master index file listing all the repos (s)he has created.
Then, when a new repo is created, they link to it using the
svn:externals prop, so that a co of the new repo would also pull that
master index file into each persons wc (obviously under an externals
directory hierarchy, since you can't pull just one file).
Of course, this is all completely scriptable by the admin, and is
probably just as objectionable to many as it is easy :)
At any rate, I can definitely see where this policy could be quite
useful (please excuse me while I think as I type :).
Most sites I have been in not only have repos for the development
groups, but also have admin repos as well. Whether they be sysadmin
repos, or SCM admin repos, etc., there always seems to be a repo
which is read-only to the majority of the SCM user base, and writable
to just a few select admin-type individuals.
This repo usually has a wealth of useful data in it, whether it be
documentation, tools, etc. This seems like a perfect place for a
site-wide/site-specific Master Repository Index file. Especially if
there is a single person/group responsible for admin'ing the SCM
environment. The advantages of this method IMO, are HUGE compared to
"hard-wiring" the policy into the tool.
The big win is total control over what this index is. It can be a
simple text file, an HTML file, a CGI script which dynamically
"finds" repos, etc. It can be anything you want. If it's just a
text file, then you could easily import this via svn:externals.
If it's html/cgi, then the web server could be auto-updated either
via updating the web server's wc, etc.
The downside I see of hardwiring policy into the tool is the lack of
flexibility. You've now dictated that everyone must do things a
certain way, which might not work for them, not to mention that
there's no easy way to do this. What I mean is this. Say that svn
is hacked to somehow create/update a master repo index. What goes
in there, and who is allowed to use 'svnadmin create' (I assume this
command would be the logical place for such a hack). If 'svnadmin
create' is hacked, does that mean that when I create a repo on my
local drive for personal use, that it's going to attempt to update
the site-wide index? That seems illogical. But, how do you control
this? Now you're talking about additions to config files or command
line options, etc., which in turn, requires more documentation, etc.
In short, this seemingly easy hack, is in reality, opening up a
pandora's can of worms :) IMO, it's far easier to settle on a
site-specific policy, then write the necessary scripts to enforce
that site-specific policy. Subversion already provides this
infrastructure, and any admin worth his paycheck should be able to
easily write a couple of scripts to make his/her life easier in this
way.
Well, that's my $.031415927 worth :)
--
Seeya,
Paul
GPG Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 11 15:45:16 2003