Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] How to handle multi-version spells

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] How to handle multi-version spells
  • Date: Thu, 12 May 2005 09:35:25 -0700

Quoting "Sergey A. Lipnevich" <sergey AT optimaltec.com>:
> These things just create more work but little gain for users. I'm
> against this.

Sergey,

I don't see what you have against this because we're /defaulting/ to the
behaviour you want (no automatic checkout) while letting the user/SA/developer
use Sorcery to maintain a latest-checkout package if they want (aka /optional/
and defaulting to /not/ do this).

I use CVS/SVN daily checkouts for a few packages. Yes, I could maintain my
own,
but why do that when I we can put it in the grimoire for other people who'd
/also/ like to do the same? Shared effort means less effort. As Andrew Levstik
has said we should probably have a big ol' warning if the user tries to do a
CVS checkout (whether they choose automatic update or not) and probably inform
them that we do not really support the CVS checkouts since we have no control
over what the user is checking out.

While you may not like this "feature", apparently others do. This feature will
cause no harm to people unless they do other than the default, and then it's
out of our hands if they don't follow our advice. If you really want to
protect
users from doing something stupid there are quite a few ways we can do that,
but
then we'd be interfering with their choice to do the equivalent of `rm -rf
/*`.

-sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




Archive powered by MHonArc 2.6.24.

Top of Page