I'll just chip in with my 2c.
I administer a network with around 10 subversion repositories, accessed
solely through Apahce/mod_dav HTTP(S). I'd have the extra step to
enabling locking on these, but I think I'd still vote for NO automatic
upgrades.
There was one case where I attempted an upgrade to svn 1.1 and very
quickly downgraded back to 1.0 after experiencing problems. I can't
remember now exactly what those problems were, but they were something
to do with Apache version. Granted in this case I never got svn 1.1 up
and running but it isn't very hard to imagine a scenario where I'd have
had the new version running for a couple of days, by which time it has
upgraded a couple of the larger repositories, and then decided to downgrade.
With only 10 repositories, and (on this box) a rubbishy scripting
language (Windows 2000 batch files), I don't have a lot of automation
going on, but I am able to write a few simple scripts. Upgrading all my
repositories from 1.1 to 1.2 format to enable locking would be as simple as:
for %x in (repos1 repos2 repos3 ... repos10) do svnadmin upgrade %x
(Assuming an "svnadmin upgrade" command which bumps the repository
version to the latest).
That will take me, what, 10 seconds?
If I had 100 or 1000 repositories instead of 10, you can be sure that
I'd have developed some better tools to perform commands over all the
repositories.
If someone is accessing using the svn client against a file:// then
chances are fairly high that the person with admin rights is sitting at
the next desk (if not the same desk). So if they try a lock command and
get a sensible message
"Lock operations require the repository to be upgraded. Please contact
your system administrator"
.. then this is hardly going to cause a problem and will alert everyone
(after reading the release notes carefully) that all their clients will
need to be upgraded first.
As for svnadmin create, I don't see that as long as the README tells you
this, the default shouldn't be to create with locking enabled. I think
that svnadmin should have a --fs-version flag (equivalent to --fs-type)
to allow creating backward-compatible repositories with the newer
program (Although it is possible to keep a 1.1 svnadmin program around
for this purpose)
As a cautious admin, I would probably upgrade just one repository at
first, and see how that runs for a week or two before upgrading the
rest. In fact, our busiest repositories right now have no need of
locking anyway (this is because those projects that need locking are
still in VSS!)
Someone with 1000 repositories and automatic (scripted) creation is
going to have far more to think about than the minor issue of adjusting
the scripts to add "--fs-version 1.1". They already have to consider
adding "--fs-type=bdb" if they want to retain old behaviour (if that
change is made).
It seems a little bit crazy to me to saddle the svnadmin create command
with defaults that are deliberately obsolete. In 6 months everyone will
be asking for 1.3 to change its behaviour again because they are sick of
adding (or forgetting to add!) the --fs-version=1.2 switch
So
svnadmin create REPOSPATH [ --fs-type=bdb|fsfs ] [
--fs-version=1.1|1.2 ]
svnadmin upgrade REPOSPATH [ --fs-version=1.1|1.2]
Actually maybe that version switch should be --fs-format= 3|4 (the
actual format value) rather than trying to track the program version.
I'm easy.
I'm also easy on whether svnadmin upgrade can DOWNGRADE, but it would be
nice to avoid a dump/load cycle.
- Walter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 26 23:46:26 2005