I'm not against doing what you suggest, I'm just a bit unsure of a usage
scenario, if you could give an example of how it would work (what would
happen and what commands would be typed), I think I would understand it
better. If I understand what you are talking about then it is similar to
what PostgreSQL does when it is updated. It leaves behind a backup of the
pgsql dump command so that when you upgrade to an incompatible format DB
then you can still easily convert your DB to the new format without having
to uninstall the new PostgreSQL, re-install the old one, dump the
database, reinstall the new PostgreSQL. Is that the usage scenario you
are talking about? If so, then yes, I like your idea.
Also, thinking about it, I think svnadmin would probably need to be
compiled statically instead of with dynamic link libraries as the user
would need for it to work even when other packages had been updated.
I wonder if there is a way to compile svnadmin statically and all the
others dynamically? Or maybe I should try to compile a static *and*
dynamic version of svnadmin and leave the static one behind when package
upgrade occurs?
- David
On Thu, 24 Oct 2002, Scott Harrison wrote:
> Hi David:
>
> It is intuitive for me to:
>
> * update all of my software
> * then bring any out-of-date configurations and database schemas up-to-date.
>
> It is counterintuitive to:
> * always remember what machines have subversion repositories
> * always remember for machines that have subversion to
> "svnadmin dump" every single repository
> * then update the subversion software and all other software
> that may have dependency issues
> * then update (or not) the format of subversion repositories
>
> Under your approach, I always have to
> svnadmin dump before every RPM upgrade
> (whether or not the db schema changes...unless
> I am tracking changes in the source code.
>
> Under your approach, I can't just willy-nilly
> have my entire system automagically update all of its
> RPMs. I have to first diagnose the locations of
> all my svnadmin repositories, and dump them, just
> in case.
>
> Sys-admin's are liable to be ignorant about
> all software on their system. Subversion will
> become mainstream, and when it does, the db format
> schema changes are going to bite hard on the blissfully
> ignorant (or at least those people who don't stare
> at a computer screen 12 hours a day like myself).
>
> Most of all, I want you to stick with an RPM packaging
> philosophy that you are comfortable with. I just
> see an opportunity here to maybe make things a little
> more user-friendly and help with the mainstream emergence
> of subversion as the repository versioning utility of choice.
> But arguably, maybe "svnadmin.rpmsave" will just confuse more
> users than it helps.
>
> Or maybe, now is the wrong time in subversion's code development
> timeline to worry about this.
>
> I should have posted this on the dev mailing list before issuezilla-ing
> it. Oops.
>
> > http://subversion.tigris.org/issues/show_bug.cgi?id=944
> >
> >
> >
> >
> >
> > ------- Additional Comments From david_subversion@tigris.org 2002-10-23 20:07 PDT -------
> > Wouldn't it just be better to always save a backup or two of your
> > repositories and RPMs? That's what I do. How will this way be better?
> > ------( NOTE )------------->
> > This E-mail was scanned for viruses by Ramcell Online (http://www.ramcell.net/antivirus.asp)
> >
>
>
--
David Wayne Summers "Linux: Because reboots are for upgrades!"
david_at_summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 24 15:27:46 2002