when to upgrade?

[Hamilton Link <he...@sandia.gov>]

I wouldn't consider myself much of an agressive tester of SVN, so much
as an early adopter of SVN (or an overly ambititous luser). I realize
there's some reason to keep up to speed with events, and keep up with
new versions, but unless I'm having trouble with something I'd rather
not upgrade every time there's a new interim release.

Would someone suggest what might be a reasonable strategy for upgrading?
Dumping and loading the database on either side of a re-installation
seems like the supported tactic, but what's a good strategy -- is it
mostly advisable when the database format changes or I encounter some
known problem, or are there good reasons for keeping up with the interim
releases?

thanks,
hamilton


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: when to upgrade?

[cm...@collab.net]

"Hamilton Link" <he...@sandia.gov> writes:

> Would someone suggest what might be a reasonable strategy for upgrading?
> Dumping and loading the database on either side of a re-installation
> seems like the supported tactic, but what's a good strategy -- is it
> mostly advisable when the database format changes or I encounter some
> known problem, or are there good reasons for keeping up with the interim
> releases?

The dump/load thing is only required when the database format changes.

As for when to upgrade, the point releases should be "basically safe"
times to upgrade.  You should at least check out the CHANGES file that
comes in each release tarball to see if the new code scratches an itch
of yours, or offers some fun new features, or fixes some bad bad
thing.  That's the best strategy I can think of for deciding when a
good time to upgrade might be.

Of course, that there are dozens of us who upgrade our instantiations
of Subversion every so many N revisions (where N is certainly < 20),
generally without detriment to our general uses of the product.  And I
think our development community is extremely quick to identify and
solve those bugs that crop up which actually do affect the usefulness
of the tool.  I'm quite proud of what our developers and volunteers
offer to the stability and quality of Subversion.  Our bleeding edge
is a gushing fountain of blood, but tourniquets are easy to come by.

Just my thotz,
--C-Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org