You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2003/04/07 17:15:21 UTC
The `on_disk' and `in_repos' templates.
This mail is about two semi-independent things: the `on_disk' and the
`in_repos' template arguments to svn_repos_create(). Their
corresponding arguments to svnadmin are:
$ svnadmin create --on-disk-template FOO --in-repos-template BAR
[I suppose I could send two separate mails, but what the heck.]
The idea behind on-disk templates was that there would be certain
repository setups admins would want to repeat over and over -- the
main thing being that one would often want the same hook files in
different repositories.
The idea behind in-repos templates is that, even though Subversion
repositories are technically free-form, in practice we want to
encourage the adoption of certain standards. (One example would be
the layout we use in Subversion's own repository.) The best way to
encourage a standard is to make it very convenient to follow the
standard; hence the templatizing.
Regarding the on-disk template:
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 would have made noise about
this earlier if I'd been better able to articulate my thoughts.
(I think there was also some miscommunication around the original
discussion of these features, but my recollection could be faulty.
Anyway, I don't really care exactly how it happened, let's just
discuss the situation as it is in the present.)
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
you don't have Python, Perl, or even Bourne shell on your box, you
have svnadmin (since you managed to build Subversion). So we could
ship a wrapper script, or scripts, but we could never advertise them
as the The One True Way to create a repository, since some people
might still have to use 'svnadmin create' to do it. Therefore, the
argument goes, it's better to have this functionality directly in
Subversion.
In the real world, though, I don't buy it. Most admins don't create
repositories all *that* often. 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). Sure, I've seen new CVS admins post questions about
setting up new repositories, but their questions are usually answered
pretty easily. I honestly don't think Subversion will see *fewer*
questions because it has the `--on-disk-template' argument; it'll just
see different questions, such as "How do I use that argument? What
does it mean?" :-)
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. 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.
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 :-).
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?
Regarding the in-repos template:
The idea behind this was to encourage a standard tree layout. Lately,
the layout we seem to have settled on (and the one that the Subversion
book is planning to document as The Recommended Layout) looks like
this:
/Project1/trunk
/branches
/tags
/Project2/trunk
/branches
/tags
In other words, there is the idea of a "project root", and the first
things under every project root are three directories: trunk,
branches, and tags. Project roots are often located in "/", but not
always. (For example, our repository has the "/clients/" directory,
which contains, say, "/clients/rapidsvn/" as one of three project
roots beneath it).
Maybe there will be repositories in the future that use slightly
different layouts, I don't know. This layout does seem to be working
pretty well, though, and I think we'd have to recommend it as at least
one of the proven layouts.
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.
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.
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.
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.
Any objections?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Apr 08, 2003 at 04:10:11PM -0500, Ben Collins-Sussman wrote:
> "Jay 'Whip' Grizzard" <el...@lupine.org> writes:
>...
> > Subversion, on the other hand, essentially _requires_ a directory structure
> > be in place at the start to be _AT ALL USEFUL_. If you don't have some sort
> > of 'meta' directory structure in place above whatever it takes to store
> > and build your project, you lose most of the power of Subversion.
>
> Oops, miscommunication here. :-)
>
> I was talking about the feature which already exists in our C API --
> namely, the ability for svn_repos_create() to build an "on disk"
> structure from a template. These are real files and directories, like
> the automatic installation of hook-scripts.
>
> You're talking about a not-yet-implemented feature, the ability to
> create an "in repos" structure (/branches, /tags, /trunk) from a
> template.
Karl was discussing nuking *both* features, so Jay is not off-topic here.
>...
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
Re: The `on_disk' and `in_repos' templates.
Posted by Jay 'Whip' Grizzard <el...@lupine.org>.
[snip]
> > of 'meta' directory structure in place above whatever it takes to store
> > and build your project, you lose most of the power of Subversion.
>
> Oops, miscommunication here. :-)
>
> I was talking about the feature which already exists in our C API --
> namely, the ability for svn_repos_create() to build an "on disk"
> structure from a template. These are real files and directories, like
> the automatic installation of hook-scripts.
Okay, okay, I'll eat my foot now. :>
I actually thought this originally, and then you started talking about
"I don't hear cvs admins complaining that there's not a built-in way to set
up their repositories" (etc) and my mind went the wrong way.
> You're talking about a not-yet-implemented feature, the ability to
> create an "in repos" structure (/branches, /tags, /trunk) from a
> template.
Yep. Which still doesn't change all that much of my message, since it
looks like a lot of folks want to kill off that feature, too (rather than
making it actually work).
> Do you also wish that a specific set of hook scripts and a standard
> DB_CONFIG file were automatically copied from a template? Just
> wondering.
Well, I do think that some things (e.g. a database-trimming post-commit
hook) should be automagically copied from a default template of some sort;
The 'basic' repository really should be useful to as many people as general,
and right now, that does require some things to be in your standard
repository that just aren't there now.
Of course, the need for 'standard' hook scripts could be reduced/eliminated
with changes in subversion (e.g. move bdb log handling internal, just to
pick a particularly well-beaten horse), which makes the argument weaker,
but I'd still hate to see the idea go away completely.
-jay
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Ben Collins-Sussman <su...@collab.net>.
"Jay 'Whip' Grizzard" <el...@lupine.org> writes:
> > I mean... look at the world of CVS. Administrators create lots of CVS
> > repositories. There are automated systems out there that create lots
> > of CVS repositories too. I have *never* heard of a complaint along
> > the lines of, "damn, I wish 'cvs init' could automatically lay out the
> > repository for me from a template.".
>
> Know why you don't hear those complaints? CVS doesn't need any sort of
> real 'repository' structure to work well, beyond what is needed to store
> and build the source.
>
> Subversion, on the other hand, essentially _requires_ a directory structure
> be in place at the start to be _AT ALL USEFUL_. If you don't have some sort
> of 'meta' directory structure in place above whatever it takes to store
> and build your project, you lose most of the power of Subversion.
Oops, miscommunication here. :-)
I was talking about the feature which already exists in our C API --
namely, the ability for svn_repos_create() to build an "on disk"
structure from a template. These are real files and directories, like
the automatic installation of hook-scripts.
You're talking about a not-yet-implemented feature, the ability to
create an "in repos" structure (/branches, /tags, /trunk) from a
template.
> > It's just not a common problem. I know the itch is intense for
> > gstein, but I think he's imagining other people have this itch too,
> > when it seems (to me) like people just don't. Automated scripts that
> > create repositories do many things, and the template feature doesn't
> > noticeably reduce the complexity of the task.
>
> Okay, quick ... who here uses roughly the same layout for every Subversion
> repository they create? I know I do ... I use /trunk /branches /tags and
> /releases,
Do you also wish that a specific set of hook scripts and a standard
DB_CONFIG file were automatically copied from a template? Just
wondering.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Brian Denny <br...@briandenny.net>.
>
> >...
> > [Example... another quick survey: Who here -genuinely- feels that putting
> > 'db_archive | xargs rm' in the default post-commit hook (not even
> > post-commit.tmpl) wouldn't be an acceptable, or even good solution for
> > 99% of the future userbase?]
>
> Personally, I agree with this. Altho I'd implement it directly in the
> svn_repos or svn_fs libraries (there is a db_archive function that can be
> called).
i don't completely understand the BDB logs issue myself; but didn't
somebody else say that it was unsafe to run db_archive without doing
a repository backup first? if that's true, it doesn't sound like a good
default post-commit action.
-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Scripting (was: The `on_disk' and `in_repos' templates.)
Posted by Stefan Monnier <mo...@rum.cs.yale.edu>.
As I kept thinking that it would be better if `svn admin ran a
script rather than have a `svn-admin script, I started to
wonder why that is.
I think it's good for programs to be scriptable easily, and it's
good to add hooks so that operations can be done at particular
times, automatically. The difference between an external script
and a natively supported hook is that the external script will
only be run if the user uses it, obviously.
This becomes particularly important when the user is separated
from the `svn' executable by a GUI layer (for example).
Now, I don't know nearly enough about those on-disk-template
and in-repos-template thingies to know what should be done, but
if it's at all possible, I think it'd be great to take them
out of the C code and put them into a default script and
have the script be run by `svn admin'.
This way, the args would still be supported, but not in C code
and they could be much more easily hacked on locally.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Apr 08, 2003 at 01:43:54PM -0700, Jay 'Whip' Grizzard wrote:
> My $0.02. I really don't have a right to an opinion here, so take with a
> large grain of salt. :>
Hell yah, you have an opinion. Everybody does. We'd be idiots not to listen
to users of the system.
Don't erroneously align the notions "allowed to have an opinion" and
"allowed to commit" :-) Just because people don't have commit doesn't mean
they should sit meekly on the sidelines.
>...
> If most people are going to call svnadmin-create-template-wrapper most of
> the time they create a repository -- why the heck should the functionality
> be in a wrapper? At that point, it seems like a pretty core part of the
> functionality of the system!
Exactly my reasoning. Thanks for stating it so much more clearly.
> ... now, I'm going to go out on a limb here and add this: Not only do I think
> that the in-repos-template stuff should be a part of svnadmin -- But I think
> that it should be enabled (with a simple, standard template) _by default_.
I'm fine with this, but deferred it until after the feature was coded.
>...
> Face it, subversion is quite hard to understand at first glance, for a lot
> of people (especially those who's primary history is with CVS), so even
> shrugging off usability issues with "Well, it'll be in the manual" isn't
> a good solution.
I tend to agree. And despite what it sounds like, I'm sure that Karl and
Ben, et all would also agree. "It should just work [as you expect it]" has
been the design for a lot of the command line interface, for example.
>...
> Recently, a lot of the messages I've seen (on these topics, specifically,
> but on others as well) have been of the opinion (roughly) that "if someone
> doesn't want to take the time to read and understand the entire manual,
> they don't deserve to get benefits from our tool". Nobody has voiced anything
> quite that directly, but that's the jist of things (think of the
> 'administrators should have to spend time to understand bdb and how to
> maintain the repositories to keep the size of the database from
> spiralling out of control' discussion).
It's a tough question. I agree that it should "just work", but [in the
concrete example] that is also balanced by "we don't want to kill the
ability to restore a corrupted repository".
I'm also generally of the opinion that an administrator *does* need to know
about the care and feeding of the systems they are running. It is our job to
make it as simple as possible for them, and as invisible and
self-maintaining as possible, but where we can't... they should know.
>...
> [Example... another quick survey: Who here -genuinely- feels that putting
> 'db_archive | xargs rm' in the default post-commit hook (not even
> post-commit.tmpl) wouldn't be an acceptable, or even good solution for
> 99% of the future userbase?]
Personally, I agree with this. Altho I'd implement it directly in the
svn_repos or svn_fs libraries (there is a db_archive function that can be
called).
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
Re: The `on_disk' and `in_repos' templates.
Posted by Brian Denny <br...@briandenny.net>.
> Well, I've probably "sold" about two dozen users on subversion, and had
> them go try to check it out, and not a single one of them has even managed
> to set up a test repository. Right now, this is because compiling Subversion
> is a true pain in the ass (to say the least), which is a pretty major
> barrier to entry. I'm sure that I'll actually get some converts when that
> problem goes away (presumably when 1.0 comes around), but subversion has
> plenty of other barriers, some high, some not, but why not lower them a
> bit more if we can, without hurting much?
I completely agree about about the compilation issues. I compile plenty
of software from sources, and subversion took me about 10 times as long
as average to get it right.
On the other hand, so far I have been finding subversion much easier both
to use and administer than CVS.
Of course, that doesn't mean that we shouldn't try to make subversion
even easier to use. But is it really that difficult for the user to
run a Python or Perl script?
And even if we do implement Feature X in C, I would err on the side of
restraint when it comes to assuming that any given 'default' is going to
suit 'most users'. You see an empty repository as an 'un-useful
default'; i see it as a blank slate, and think it is better to provide
such a blank slate than to provide a positive structure that might not
be wanted.
-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Jay Whip Grizzard <el...@lupine.org>.
> Hey hey, hold on a second here. I have several repositories that I find very
> useful, and none of them follow the bog-standard layout.
Go back and re-read what I wrote. I was not -- at all -- trying to imply
that there should be "one standard layout" to repositories, or even,
really, that the "standard" layout folks here use is the best layout (or
even a good one (though I, personally, am rather fond of it)).
What I -am- trying to say is that the current -default- layout (which is
a completely empty repository) is probably not very useful to your
average person-on-the-street who's just trying to get CVS-like functionality
without all the CVS-like cruft, which I suspect will be quite a large
percentage of Subversion's ultimate userbase.
> Anyway, I don't disagree with the idea of repository templates. They can be
> useful, especially if you are creating repos for C projects all day. I don't
> even object to having a template applied by default, as long as I can turn it
> off. But I do take issue with your statement that repos without an
> authoritative structure will cease to be useful in the long term;
Again, see previous. I didn't say you needed 'an authoritative' structure,
I said you needed -A- structure. You have to have -some- structure as
default (even if that structure is 'empty'), and the default should really
be the simplest structure that is useful to the largest number of people
right off the bat (even if that sentence doesn't make complete sense :).
A 'no structure' repository is -not- useful to a large number of people.
[The fact (theory?) that 99% of this list probably immediately follows
their 'svnadmin create' with a 'svn mkdir' to make some meta-structure
demonstrates that, I think.]
I don't propose anyone dictate standards. I propose that in absense of a
user explicitly requesting something different, the 'empty' structure
they get when making a new repository be more useful than 'no structure'.
> and I also think you are overstating Subversion's 'barriers to entry'.
Well, I've probably "sold" about two dozen users on subversion, and had
them go try to check it out, and not a single one of them has even managed
to set up a test repository. Right now, this is because compiling Subversion
is a true pain in the ass (to say the least), which is a pretty major
barrier to entry. I'm sure that I'll actually get some converts when that
problem goes away (presumably when 1.0 comes around), but subversion has
plenty of other barriers, some high, some not, but why not lower them a
bit more if we can, without hurting much?
-jay
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Ben Gollmer <be...@jatosoft.com>.
On Tue, 8 Apr 2003 15:43:54 -0500, Jay Whip Grizzard <el...@lupine.org>
wrote:
[ snip snip ]
> Subversion, on the other hand, essentially _requires_ a directory structure
> be in place at the start to be _AT ALL USEFUL_. If you don't have some sort
> of 'meta' directory structure in place above whatever it takes to store
> and build your project, you lose most of the power of Subversion.
>
> ... now, I'm going to go out on a limb here and add this: Not only do I
think
> that the in-repos-template stuff should be a part of svnadmin -- But I think
> that it should be enabled (with a simple, standard template) _by default_.
> The current 'standard' layout has come about through real-world trials and
> tribulations, and there's no good reason to force someone to read -- and
> comprehend -- the entire manual just to be able to create a repository
that's
> going to be useful in the long term.
Hey hey, hold on a second here. I have several repositories that I find very
useful, and none of them follow the bog-standard layout.
> Face it, subversion is quite hard to understand at first glance, for a lot
> of people (especially those who's primary history is with CVS), so even
> shrugging off usability issues with "Well, it'll be in the manual" isn't
> a good solution. Me personally, I read the Subversion manual over several
> times and monitored the mailing list(s) for months before I actively started
> using Subversion in real-world projects, and I -still- didn't have a
complete
> grasp over everything I eventually ended up needing to know. And I'm one of
> those (apparently rare) people that ENJOYS reading the manual and usually
> reads it thouroughly before even touching most software.
>
> Subversion has a per-user config file. If you don't want templates by
> default, make a config option that specifies the default template name,
> and set it to 'none' (or 'empty', or whatever). Problem solved. You
> obviously already know quite a lot about subversion if you're going to
> want to start every repository completely empty (IMHO). Don't make John Doe
> newbie need to comprehend the entire manual just so that he can have a
> usable tool.
When I started using Subversion, I made my first few repos using the '/branches
/tags /trunk' layout because I had been led to believe it was the One True Way
of managing a repo. But shortly, I realized that Subversion was so flexible that
I didn't need to bother with such conventions.
It didn't take a long study session with the manual to figure this out, either.
Basically you just need to understand two things; namely, 'Copies Are
Cheap(tm)', and 'There's More Than One Way To Do It' (ok, everyone here
seems to use Python over Perl, but you get the point). Most of the stuff I keep
in my repos isn't even code, thanks to Subversion's handling of binary files &
MIME types, and creative layouts can be very helpful.
Anyway, I don't disagree with the idea of repository templates. They can be
useful, especially if you are creating repos for C projects all day. I don't
even object to having a template applied by default, as long as I can turn it
off. But I do take issue with your statement that repos without an authoritative
structure will cease to be useful in the long term; and I also think you are
overstating Subversion's 'barriers to entry'.
--
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Jay 'Whip' Grizzard <el...@lupine.org>.
My $0.02. I really don't have a right to an opinion here, so take with a
large grain of salt. :>
> I mean... look at the world of CVS. Administrators create lots of CVS
> repositories. There are automated systems out there that create lots
> of CVS repositories too. I have *never* heard of a complaint along
> the lines of, "damn, I wish 'cvs init' could automatically lay out the
> repository for me from a template.".
Know why you don't hear those complaints? CVS doesn't need any sort of
real 'repository' structure to work well, beyond what is needed to store
and build the source.
Subversion, on the other hand, essentially _requires_ a directory structure
be in place at the start to be _AT ALL USEFUL_. If you don't have some sort
of 'meta' directory structure in place above whatever it takes to store
and build your project, you lose most of the power of Subversion.
That's a pretty big difference.
> It's just not a common problem. I know the itch is intense for
> gstein, but I think he's imagining other people have this itch too,
> when it seems (to me) like people just don't. Automated scripts that
> create repositories do many things, and the template feature doesn't
> noticeably reduce the complexity of the task.
Okay, quick ... who here uses roughly the same layout for every Subversion
repository they create? I know I do ... I use /trunk /branches /tags and
/releases, at the moment, every time. I actually recently investigated (and
found out it wasn't implemented) the template feature because I was getting
tired of always creating these directories by hand.
Now, of you who use roughly the same layout for every Subversion repository
you make (I suspect that's most of you)... If there was a 'standard' wrapper
around svnadmin to set up repositories from a template, would you create
the majority of your repositories with this wrapper?
I suspect the answers for most people are 'yes' and 'yes', respectively.
(If your answers are 'yes' and 'no', respectively ... what are you, some kind
of masochist?). So assuming that's true, I have to ask:
If most people are going to call svnadmin-create-template-wrapper most of
the time they create a repository -- why the heck should the functionality
be in a wrapper? At that point, it seems like a pretty core part of the
functionality of the system!
... now, I'm going to go out on a limb here and add this: Not only do I think
that the in-repos-template stuff should be a part of svnadmin -- But I think
that it should be enabled (with a simple, standard template) _by default_.
The current 'standard' layout has come about through real-world trials and
tribulations, and there's no good reason to force someone to read -- and
comprehend -- the entire manual just to be able to create a repository that's
going to be useful in the long term.
Face it, subversion is quite hard to understand at first glance, for a lot
of people (especially those who's primary history is with CVS), so even
shrugging off usability issues with "Well, it'll be in the manual" isn't
a good solution. Me personally, I read the Subversion manual over several
times and monitored the mailing list(s) for months before I actively started
using Subversion in real-world projects, and I -still- didn't have a complete
grasp over everything I eventually ended up needing to know. And I'm one of
those (apparently rare) people that ENJOYS reading the manual and usually
reads it thouroughly before even touching most software.
Subversion has a per-user config file. If you don't want templates by
default, make a config option that specifies the default template name,
and set it to 'none' (or 'empty', or whatever). Problem solved. You
obviously already know quite a lot about subversion if you're going to
want to start every repository completely empty (IMHO). Don't make John Doe
newbie need to comprehend the entire manual just so that he can have a
usable tool.
... which brings me to another, related topic.
Recently, a lot of the messages I've seen (on these topics, specifically,
but on others as well) have been of the opinion (roughly) that "if someone
doesn't want to take the time to read and understand the entire manual,
they don't deserve to get benefits from our tool". Nobody has voiced anything
quite that directly, but that's the jist of things (think of the
'administrators should have to spend time to understand bdb and how to
maintain the repositories to keep the size of the database from
spiralling out of control' discussion).
It's an arrogant stance, though amazingly common amongst unix users/admins,
I've found. But every time I see something like this, I have to fight back
the urge to start screaming at people. These applications do _NOT_ have to
be hard to use, and there's no reason to intentionally make them harder
to use because 1% of the future userbase might have to intentionally disable
some usability feature because it doesn't suit them.
[Example... another quick survey: Who here -genuinely- feels that putting
'db_archive | xargs rm' in the default post-commit hook (not even
post-commit.tmpl) wouldn't be an acceptable, or even good solution for
99% of the future userbase?]
By 'future userbase' I mean 'those who would (or will) switch to subversion
as soon as the version number is stable and the barrier to entry is
acceptably low.
-jay
(Not a subversion developer, but an active subversion user, a heavy
subversion advocate, and a person getting durned tired of people she
advocates to not using subversion because the barrier to entry is so
high... and it IS high...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by kf...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> That is just side-stepping the issue. Josef's point is that we have not
> provided any useful feedback about his script. And that its existence is
> very much tied to whether the APIs should remain or not. That is: if you
> decide to lose the functionality, then the importance of his CGI is
> increased. And the contrary, of course.
Sorry, that's certainly a point.
Josef, in case this is useful data for you: I actually had an entire
paragraph that was basically the same as what Greg wrote (about how a
CGI script is not the same as a command-line script). I deleted that
paragraph before I sent my mail, because I knew it had been said
before in earlier threads, and I didn't want to repeat points you'd
already heard. Perhaps I should have kept it -- it might have made my
reaction more easily comprehensible.
The CGI script is very useful, of course. But there's a certain
overhead to just running the Web server and setting up the script, and
even then it's not command-line batchable in the same way. That's why
I don't class it as a general purpose solution, but instead as a good
solution for a certain subset of users.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Apr 08, 2003 at 03:07:30PM -0500, Karl Fogel wrote:
> Josef Wolf <jw...@raven.inka.de> writes:
> > What the heck? You are arguing back and forth whether to catch the fly
> > or not. But no one have given any response to the _already_ _existing_
> > solution that is _already_ more powerful than the simple templates you
> > are debating about. Are you that infected by the NIH-syndrome that you
> > do not even take a look on _already_ _existing_ solutions? I admit
> > that this solution is far away from beeing perfect. But it already
> > solves (not only) the problems you are debating about. Just go ahead
> > and take a look at it and say what you dislike in it.
>
> Are you talking about the CGI script, Josef?
>
> The proposal under discussion is about getting the solution out of the
> C API, on the grounds that external solutions are better. So if
> you're claiming that your external solution is one such, then great;
> and if you're not, that's fine too. It doesn't affect this discussion
> much either way.
That is just side-stepping the issue. Josef's point is that we have not
provided any useful feedback about his script. And that its existence is
very much tied to whether the APIs should remain or not. That is: if you
decide to lose the functionality, then the importance of his CGI is
increased. And the contrary, of course.
Josef: I know that I haven't really responded because using a CGI for basic
operation is even less interesting to me than a wrapper script which is less
than integrating into svnadmin. To have to set up a web server and a CGI
script to get this functionality... that's just too much for me. Second, I
don't like the security implications of such a system. I don't like seeing
that much privilege/power in a CGI script, although (to be fair) my security
issue is second to the former and is mostly based on ignorance of the script
and a lack of detailed review.
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
Re: The `on_disk' and `in_repos' templates.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Josef Wolf <jw...@raven.inka.de> writes:
> What the heck? You are arguing back and forth whether to catch the fly
> or not. But no one have given any response to the _already_ _existing_
> solution that is _already_ more powerful than the simple templates you
> are debating about. Are you that infected by the NIH-syndrome that you
> do not even take a look on _already_ _existing_ solutions? I admit
> that this solution is far away from beeing perfect. But it already
> solves (not only) the problems you are debating about. Just go ahead
> and take a look at it and say what you dislike in it.
Are you talking about the CGI script, Josef?
The proposal under discussion is about getting the solution out of the
C API, on the grounds that external solutions are better. So if
you're claiming that your external solution is one such, then great;
and if you're not, that's fine too. It doesn't affect this discussion
much either way.
Don't be so prickly :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Ben Collins-Sussman <su...@collab.net>.
Josef Wolf <jw...@raven.inka.de> writes:
> On Tue, Apr 08, 2003 at 11:22:39AM -0500, Ben Collins-Sussman wrote:
> > Karl Fogel <kf...@newton.ch.collab.net> writes:
> > > Ben Collins-Sussman <su...@collab.net> writes:
>
> [ lots of arguing deleted ]
>
> What the heck? You are arguing back and forth whether to catch the fly
> or not. But no one have given any response to the _already_ _existing_
> solution that is _already_ more powerful than the simple templates you
> are debating about. Are you that infected by the NIH-syndrome that you
> do not even take a look on _already_ _existing_ solutions? I admit
> that this solution is far away from beeing perfect. But it already
> solves (not only) the problems you are debating about. Just go ahead
> and take a look at it and say what you dislike in it.
Sorry, don't mean to ignore your solution.
Karl and I are merely arguing to remove the the current solution from
the C API. Once we all agree that the solution should exist in the
world of scripting, then it makes sense to start evaluating particular
scripting solutions. We're just not there yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Josef Wolf <jw...@raven.inka.de>.
On Tue, Apr 08, 2003 at 11:22:39AM -0500, Ben Collins-Sussman wrote:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
> > Ben Collins-Sussman <su...@collab.net> writes:
[ lots of arguing deleted ]
What the heck? You are arguing back and forth whether to catch the fly
or not. But no one have given any response to the _already_ _existing_
solution that is _already_ more powerful than the simple templates you
are debating about. Are you that infected by the NIH-syndrome that you
do not even take a look on _already_ _existing_ solutions? I admit
that this solution is far away from beeing perfect. But it already
solves (not only) the problems you are debating about. Just go ahead
and take a look at it and say what you dislike in it.
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
> > It's just not a common problem. I know the itch is intense for
> > gstein, but I think he's imagining other people have this itch too,
> > when it seems (to me) like people just don't. Automated scripts that
> > create repositories do many things, and the template feature doesn't
> > noticeably reduce the complexity of the task.
>
> Yah.
>
> Btw, to be fair, at the time Greg first described/implemented it, I
> also thought the on_disk template could be useful. It's only over
> time that it's begun to feel like needless baggage to me.
I don't mean to trivialize the problem completely. I'm just saying
it's not worth a Buick-level solution (C API). Somebody please just
create an appropriate-sized flyswatter instead (e.g. tools/create-repos.py).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> It's just not a common problem. I know the itch is intense for
> gstein, but I think he's imagining other people have this itch too,
> when it seems (to me) like people just don't. Automated scripts that
> create repositories do many things, and the template feature doesn't
> noticeably reduce the complexity of the task.
Yah.
Btw, to be fair, at the time Greg first described/implemented it, I
also thought the on_disk template could be useful. It's only over
time that it's begun to feel like needless baggage to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> 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.
This is sort of how I feel about the issue.
I mean... look at the world of CVS. Administrators create lots of CVS
repositories. There are automated systems out there that create lots
of CVS repositories too. I have *never* heard of a complaint along
the lines of, "damn, I wish 'cvs init' could automatically lay out the
repository for me from a template.".
It's just not a common problem. I know the itch is intense for
gstein, but I think he's imagining other people have this itch too,
when it seems (to me) like people just don't. Automated scripts that
create repositories do many things, and the template feature doesn't
noticeably reduce the complexity of the task.
I feel like we're swatting a fly with a Buick. Whether the problem is
a "fly" is subjective I guess... maybe only answerable by survey, as
kfogel suggests. But for me, the solution is a "Buick" the minute our
public C API grows new arguments. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@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
Re: The `on_disk' and `in_repos' templates.
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, April 8, 2003 9:09 AM -0500 cmpilato@collab.net wrote:
> Svnlook exists in C for ease of installation. To *require* swig and
> python bindings just to get a really basic repos looker tool is silly,
> IMO.
I consider myself lucky if I get the SWIG python bindings to compile about
half the times I compile SVN itself. I usually give up in frustration. I
think there is some overestimation on how many people are actually building
the bindings without problems. I think the template feature is useful enough
to always be available without fighting SWIG or Python. (Hello, SWIG/Python
bindings on Windows? Ha-ha.)
Furthermore, by exposing it at the API level, it allows new GUIs to be able to
deliver this functionality at essentially zero additional cost. That's a good
thing, I think. By removing this from the API, new GUIs will not have a way
of adding this feature (consistently).
Personally, the templates make it so I have to do one less step when creating
my repositories. I don't care much what SourceForge or *cough* any other
system does - those monkeys get paid lots of $$ to deal with it. I want
something that I don't *need* to write shell scripts to customize it.
SVN is there to scratch my needs not anyone else's. =) (I feel like Branko.)
-- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by cm...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> 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?
[Not weighing in on the repos template debate ... just rebutting
Greg's exaggerated conclusion here]
Svnlook exists in C for ease of installation. To *require* swig and
python bindings just to get a really basic repos looker tool is silly,
IMO.
And about using C code for tasks more easily done in scripting? I
think our C code can handle path construction just fine without too
much pixie dust. Don't overstate what svnlook does -- half of the
subcommands just print property values, trivially accessible via the
svn_repos interface. The rest just prints nodes in a linked list.
The only really ugly subcommand is 'diff'.
All that said, once our bindings are fully and reliably handled in our
build system (on all platforms), once they've matured enough, and once
I'm convinced that Swig is becoming more widespread in its usage, I'd
be *completely* willing to discuss the permanent replacement of
svnadmin and svnlook with Python scripts! :-)
[I now return you to your regularly scheduled argument]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Greg Stein <gs...@lyra.org>.
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.
Re: The `on_disk' and `in_repos' templates.
Posted by Branko Čibej <br...@xbc.nu>.
I almost blundered into this discussion about pros and cons of
integrated template support, but then realised there are enough opinions
flying around already. So I'll just bring up a few points that I think
need consideration, regardless of whether the template support is built
in or scripted
* Installation. Where are the templates installed, on various
systems? Do you have a single set of templates, or separate sets
for different project groups?
* Integration. Does the default repository (on-disk) layout remain
hard-coded, or does it gradually move into the on-disk templates?
What does such a move do to ease of installation?
* Maintainability. How do you maintain/modify the templates? How do
you document them? What tools do you need (e.g., for locating the
template installation, etc.)
* Filesystem features (for in-repos templates). What features of the
filesystem can you control with the templates? Directory layout,
properties, revprops?
* Back-end features (for on-disk templates): Again, what features of
the on-disk structure can you control with the templates? Thinking
ahead, can the template idea be extended to non-Berkeley
back-ends? What about DB_CONFIG or equivalent configuration files?
Does the template determine the back-end type, or the other way
around?
In short, what I'm asking for is a design discussion, starting with
basic requirements. Templates of any kind are potentially a very useful,
but also potentially large, feature. Let's not make the same mistake
with templates as we made with the working copy, where we just sort of
bunched ideas together into code until it all beame an unmaintainable mess.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The `on_disk' and `in_repos' templates.
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Monday, April 7, 2003, at 01:15 PM, Karl Fogel wrote:
> 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?
+1
> 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.
+1
i agree with karl's arguments on both these points. both seem like
added complexity when it isn't especially necessary.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org