On Mon, Apr 07, 2003 at 12:15:21PM -0500, Karl Fogel wrote:
>...
> The argument against this "just use a wrapper" strategy, of course, is
> that a wrapper would not be as portable as svnadmin itself. Even if
This is a big one. Without it built into svnadmin, then you need different
solutions for the different platforms. Different doc and different issues.
>...
> In the real world, though, I don't buy it. Most admins don't create
> repositories all *that* often.
Morbius has got a bunch. I've got a half-dozen on my machine. Each time I
create one, I've gotta go through and verify that the hooks are set up
properly and copy over a bunch of files, and whatnot. It's a pain in the
ass. Templates make the job of an admin way easier.
Speaking as an admin, I disagree with your statement. I'm an empirical
statement that the use case *does* exist.
> 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).
Again, I disagree. In my case, I create a new repos (with the appropriate
hooks and whatever), and then I edit the system's mailer.conf. All the hook
script directories are the same, pointing to the same mailer.py and
mailer.conf. If I forget to edit mailer.conf, then the defaults take over
and the first commit drops into my email box telling me I'm a loser.
>...
> There are sites (SourceForge, for example) that create new
> repositories in large numbers. But in systems like that, you can be
> even more sure that `--on-disk-template' is not going to help them
> much.
I disagree. I know of a particular system (*cough*) that could use this
feature to its advantage. Sure, other stuff happens around the system, but
having a standard SVN template beats hand-rolling the stuff.
> SourceForge and similar systems *already* have custom code
> wrapping repository creation, and by necessity they have people who
> understand repository creation intimately. If they use Subversion,
> it's no trouble for them to add a couple of lines of code to copy some
> hook scripts... Certainly, no more trouble than it would be for them
> to understand the --on-disk-template argument, make a template, and
> pass the argument correctly. From the user perspective, these two
> tasks are pretty much equal in complexity.
Disagree. I don't understand how you can make this value judgement. To me,
it is always easier if the tool provides the functionality out of the box
rather than needing to roll my own.
> 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 :-).
svn_repos, actually.
But hey... by this argument, I'll just go delete svnlook. It's a lot of
complex code creating a maintenance burden. It's a needless, dormant bug
source in Subversion, and it uses C code for tasks which are more easily and
flexibly done in scripting. Blecch -- me no like :-)
And hey, Mike and I have even ported it from C to Python. It is demonstrably
replaceable by scripts, so why does it exist in C?
> So there you have it. I don't think the --on-disk-template argument
> really helps anyone, and it hurts us. I'd like to get rid of it.
> Does anyone object?
Yes :-)
>...
> 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.
For *your* particular use case, yes. The templates exist to support *other*
use cases. Again, I know of a particular system which places projects at the
root, so the layout *is* automatable. Also, I look at morbius and note that
the tendency is towards one project per repos, so the layout is automatable.
> 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.
Ah. So a person needs Python and the bindings to get himself a useful
repository? Blecch -- me no like :-)
Over the past week, we've been getting beat up on the BDB admin demands. The
message that is coming through is "make it damned simple out of the box."
> While we should do everything we can to promote a standard layout, to
> encourage easier cooperation, we shouldn't be coding it into
> `svnadmin' (and certainly not into the svn_fs API). We can do it just
> as well via documentation and examples and scripts.
Eh? It isn't being coded in. That is the entire reason for the templates.
> And note that the feature is not actually implemented anyway! The
> in_repos_template argument to svn_repos_create() does nothing right
> now [though the doc string neglects to mention this, tsk tsk]. Thanks
> to Makl, who mentioned this in issue #1222.
Don't "tsk tsk" about the doc string. About not returning an error such as
UNSUPPORTED_FEATURE, sure. We've got a number of APIs that will return
errors for certain parameter uses. Check out svn_fs_deltify() sometime.
> I'd like to remove the `--in-repos-template' flag from svnadmin, and
> from the FS api as well; it was a noble intention, but I think in the
> light of experience, it does not hold up as a solution.
How can we have experience with the feature if it hasn't been completed?
And again, we're talking the repos api, not the FS. Have you looked at the
code? :-)
> Any objections?
Yes. For much of the same reasons as the other param. Portability and built
in features that administrators will want to use to get repositories up and
running.
From my own experience as an SVN administrator, both of these parameters are
very, very useful.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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:09:33 2003