Re: [Issue 944] - Adjust future RPM packages to save former svnadmin binaries

[David Summers <da...@summersoft.fay.ar.us>]

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@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

Re: [Issue 944] - Adjust future RPM packages to save former svnadmin binaries

["Edward S. Marshall" <es...@logic.net>]

On Thu, 2002-10-24 at 08:26, David Summers wrote:
> 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.

Would a better idea here possibly be something along the lines of what
Red Hat currently does for out-dated (but still-needed) libraries, ie.
create a compat-subversion<version> package that supplies the necessary
libraries and command-line utilities for a version from an old version?

See Red Hat 8.0's compat-db for a rough idea of what I'm suggesting.

-- 
Edward S. Marshall <es...@logic.net>
http://esm.logic.net/