Greg Stein <gstein@lyra.org> writes:
> > 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.
Or, you can document a Python script, and people who are creating
repositories a lot can just get Python (which they'll almost certainly
want to do anyway).
Let's not overstate the portability issue.
> > 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 if you'd had to use a Python script instead of `svnadmin', would
your life have been harder? Nah.
You're proof that people create multiple repositories. Heck, so do I.
But it certainly doesn't mean that having this functionality in
`svnadmin' is really making your life any easier. You're using
mailer.py, so I *know* you have Python :-).
> > 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.
No, I'm sorry, it just doesn't make things any easier. You know that
part of the code in the *cough* system as well as I do -- and note
that it does not use these templates right now, and IMHO doesn't incur
any noticeable maintenance burden from that.
> 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.
I'm not saying Subversion shouldn't provide this stuff. But from the
tools/ area, not built into svnadmin. I'm saying K.I.S.S. ;-)
> > 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.
Yah, sorry, I misspoke.
> 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 :-)
I think that comparison is bogus. People *need* svnlook to get basic
hook functionality. We have to ship that, and it can't depend on SWIG
bindings.
But the wrappers I'm talking about wouldn't depend on SWIG; *and*
Subversion is quite useful without them, since they're so simple that
their functionality could be mimicked by a handwritten script or even
just manual actions.
Apples and oranges. `svnlook' is solving a different problem.
> > 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 :-)
Yah -- thought so :-).
> 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.
And Morbius has Python...
So far, every example repository server you've brought up is known to
have common scripting languages available, and admins who are
comfortable using them. Maybe that's not always the case, but so far,
the raw data says we don't need this functionality in C code.
(The same can't be said for SWIG-dependent stuff, as
Python+SWIG+bindings is a much more complex to install than just
Python alone.)
> > 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 :-)
No, they don't at all *need* SWIG to get a useful repository, and I
never claimed they did. You can even get the subdirs all in one
revision without using SWIG, c'mon, you know that :-).
I was suggesting a particular implementation, not requiring it.
> 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."
I think that's oversimplifying the issue -- and I *don't* think these
templates make it "damned simple". They're hard to explain, clumsy to
document, and are more likely to cause confusion than help people.
Yes, that's a value judgement :-). You want to take a survey of users
on the dev list? I'll bet we'll find that most people didn't know or
had ignored both kinds of templates; that of the remaining people, a
few had tried to understand them and decided they weren't worth the
effort, and that (maybe) a couple of people actually *use* them.
(You wrote the feature, we can't consider you a data point. The
important question is how useful do people find this when they have to
learn it from scratch.)
> 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.
Again, you wrote the feature(s). (Though since one of them doesn't
actually exist, your "experience" can't really be proving that it's
useful to you, as you pointed out earlier.)
For people who didn't write the features, are they proving useful? I
very much doubt it.
I'm willing to actually conduct that survey, assuming you would also
consider the results to be significant, whatever they portend. (I
promise to phrase the questions neutrally :-) ).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 8 17:02:03 2003