Karl Fogel wrote:
[ About templates ... ]
Please take a look at the svn-admin CGI script I posted on this list
some months ago. It supports templates on creation of repositories.
In addition to initial directories/files, the templates can describe
initial property settings, commit permissions and commit-email settings.
You can find the script on
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=218353
This script has somewhat evovled since I posted it (mainly cleanups
and sanity checks). I have not reposted it because I have got no
responses that anyone would be interested.
> I think this functionality should be implemented as a wrapper script
> around svnadmin, since it's essentially a matter of copying some
> files, instead of by svnadmin itself.
I think repository administration is more than only copying some
files somewhere. You have to set up _and_ maintain access
permissions, commit emails, hook scripts, backups, commit-logs
etc/pp.
> The argument against this "just use a wrapper" strategy, of course, is
> that a wrapper would not be as portable as svnadmin itself.
Implementing it as a CGI makes it pretty much portable, at least for
Apache-based repositories. Other RA-layers could be targetted by
adding additional frontends (Tk, command-line).
> Even if
> you don't have Python, Perl, or even Bourne shell on your box, you
> have svnadmin (since you managed to build Subversion).
But not having Python/Perl/Bourne-shell would make at least the
contributed hook-scripts unusable, too. While you can copy arbitrary
executables into the hook-directory, you need to understand their
configuration in order to maintain them. Thus, the hook-functionality
and the tool that is used for their maintanance are coupled very
tightly together. This is the reason why the above mentioned script
offers the frontend _and_ the hook-functionality at the same time.
> In the real world, though, I don't buy it. Most admins don't create
> repositories all *that* often.
This is why the above mentioned script is designed for creation _and_
maintanance of the repository.
> And when they do need to customize a
> newly-created repository, their customization needs generally won't be
> satisfied by the limited set of actions available through
> `--on-disk-template' (basically, all it can do is copy, and that's
> rarely enough).
Yes. You definitely want the ability for maintanance. You create the repos
only once but you maintain it as long as it lives.
> But they're not equal in code complexity. By supporting the
> templating internally, we've added a maintenance burden to our code
> (including even to the svn_fs API at the moment, which is really sad).
> It's a needless, dormant bug source in Subversion, and it uses C code
> for tasks which are more easily and flexibly done by scripting.
> Blecch -- me no like :-).
Then please, go ahead and take a look at the above mentioned script.
It _already_ does much more than I would like to implement/maintain
in C. And I think it should do a lot more than it does now.
> I don't mean to start a thread about layouts. My main point is, this
> particular layout isn't susceptible to automation at repository
> creation time, because the layout happens when you create a new
> project root. Again, the right solution is a wrapper script
> "svn-project-create.py" or something. The script could use the fs
> bindings to create the project and all three subdirs in one txn, so it
> only uses 1 revision instead 4.
Again, such a script already exists. Please go ahead and take a look at
it. I would like to hear opinions whether this is the right direction
to go and what should be changed in order to be contributed along with
subversion. If you acknowledge that this is the way to go, I will repost
the current version so that you can review it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 8 12:58:20 2003