[Dev] unsubscribe

Mon Jul 26 23:56:56 PDT 2004


> -----Original Message-----
> From: dev-bounces at osafoundation.org 
> [mailto:dev-bounces at osafoundation.org] On Behalf Of 
> dev-request at osafoundation.org
> Sent: Monday, July 26, 2004 9:08 PM
> To: dev at osafoundation.org
> Subject: Dev Digest, Vol 10, Issue 20
> 
> 
> Send Dev mailing list submissions to
> 	dev at osafoundation.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.osafoundation.org/mailman/listinfo/dev
> or, via email, send a message with subject or body 'help' to
> 	dev-request at osafoundation.org
> 
> You can reach the person managing the list at
> 	dev-owner at osafoundation.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dev digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Version control systems (Greg Noel)
>    2. Re: Version control systems (Denis Hennessy)
>    3. Notes on using super() (Donn Denman)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 25 Jul 2004 13:00:12 -0700
> From: Greg Noel <Greg at san.rr.com>
> Subject: Re: [Dev] Version control systems
> To: Morgen Sagen <morgen at osafoundation.org>
> Cc: OSAF Development <dev at osafoundation.org>
> Message-ID: <3D54C440-DE75-11D8-AA23-000393ABC40E at san.rr.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> 
> On Friday, Jul 23, 2004, at 12:28 US/Pacific, Morgen Sagen wrote:
> 
> > Since performance principle number 2 listed at 
> > http://gnuarch.org/arch-tech.html is: "Disk space is 
> cheap", one would 
> > get the impression that Arch also is not shy about using 
> lots of disk. 
> > :-)
> 
> They have a similar attitude toward CPU time and memory; there's a 
> distinction between "cheap" and "free" that they don't seem to get.  
> Good design is a balance of tradeoffs; you can't just ignore 
> them.  The 
> GNU folks have a bad habit of not spending enough time on design and 
> end up wasting all three (often at the same time) when a 
> better design 
> would be faster, smaller, and scale better.  (This is a bone I've 
> picked with them in the past; don't get me started.)
> 
> > Since I haven't actually used Arch, I don't know how this pans out 
> > during real day-to-day use.
> 
> Take this with a grain of salt, since I've never evaluated 
> arch, but as 
> I understand it, arch chews up space on the server side, not 
> the client 
> side.  It also uses forward deltas, so a number of operations 
> are very 
> expensive, to the point that it's recommended that archives be 
> essentially recreated regularly, so that you end up with disconnected 
> segments of development.  (It's also a lot less mature, so these are 
> things that may be cured eventually.)
> 
> As for the client side, my understanding is that the simplest (and 
> default) configuration keeps only one copy.  However, if you choose, 
> you can create a distributed mirror and work against a local archive 
> instead of a remote one, and have all the advantages of disconnected 
> operation.  In other words, if you have the space, you can chose to 
> spend storage to improve your own performance; it's not something 
> forced on you.
> 
> > So far the chandler CVS module is around 11MB, so in the 
> grand scheme 
> > of things disk-space usage will probably rank low on the list of 
> > deciding issues.
> 
> It's only 11Mb now, but by the time it grows to a stable 
> size, it will 
> add lots more icons, some larger pictures (think of a splash frame), 
> hopefully lots of tests, and a whole bunch of code.  It's going to 
> double, and double again.  If the eventual size is closer to 50Mb, 
> "wasting" that much space for every client checkout is a 
> _big_ chunk of 
> disk.
> 
> I'm not saying this is a fatal impediment, but as you point out, it's 
> good to have all the pros and cons.  It would affect me personally; I 
> run PPC-based Linux machines (and some Macs) and I have the habit of 
> tracking open-source projects and compiling them to make sure 
> they run 
> with my systems.  I have about 200Gb worth of sources 
> currently and my 
> disk bays are full.  If projects start converting to Subversion, I'm 
> going to have to start dropping projects.
> 
> > ...  Actually, I just found this document from someone who 
> has spent 
> > some time looking at Subversion, Arch, and Monotone (somewhat): 
> > http://www.dwheeler.com/essays/scm.html<smime.p7s>
> 
> An interesting document; thanks for bringing it to my attention.  It 
> has some additional pros and cons that should be mined out, but it 
> basically reinforces my personal assessment that Subversion 
> doesn't add 
> enough over CVS at this point and that arch is too young (and 
> insecure) 
> to be trusted for mission-critical use.  In another year or 
> two, things 
> will be different and it'll be worth reexamining.
> 
> -- Greg Noel, retired UNIX guru
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Sun, 25 Jul 2004 22:39:46 +0100
> From: Denis Hennessy <denis at hennessynet.com>
> Subject: Re: [Dev] Version control systems
> To: Greg Noel <Greg at san.rr.com>
> Cc: OSAF Development <dev at osafoundation.org>,	Morgen Sagen
> 	<morgen at osafoundation.org>
> Message-ID: <410428A2.5060208 at hennessynet.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> 
> > It's only 11Mb now, but by the time it grows to a stable 
> size, it will 
> > add lots more icons, some larger pictures (think of a 
> splash frame), 
> > hopefully lots of tests, and a whole bunch of code.  It's going to 
> > double, and double again.  If the eventual size is closer to 50Mb, 
> > "wasting" that much space for every client checkout is a 
> _big_ chunk 
> > of disk.
> >
> > I'm not saying this is a fatal impediment, but as you point 
> out, it's 
> > good to have all the pros and cons.  It would affect me 
> personally; I 
> > run PPC-based Linux machines (and some Macs) and I have the 
> habit of 
> > tracking open-source projects and compiling them to make 
> sure they run 
> > with my systems.  I have about 200Gb worth of sources 
> currently and my 
> > disk bays are full.  If projects start converting to 
> Subversion, I'm 
> > going to have to start dropping projects.
> >
> For me, having a second copy of source files on a client is a 
> very small 
> price to pay for much faster client operations (many 
> operations happen 
> without any network activity and commits only send the diffs). If all 
> you do is grab the source to have a look at it, then you 
> don't need to 
> keep the copy; just get it with wget instead of svn checkout 
> using the 
> same url.
> 
> /dh
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 26 Jul 2004 07:16:05 -0700
> From: Donn Denman <donndenman at mac.com>
> Subject: [Dev] Notes on using super()
> To: dev at osafoundation.org
> Message-ID: <54D97B50-DF0E-11D8-A251-000A95A83CE8 at mac.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> 
> I've written up some notes on using super() for the wiki:
> http://wiki.osafoundation.org/twiki/bin/view/Chandler/UsingSuper
> 
> I'm pretty new to Python, so there could be a lot of holes in the 
> information presented here, but I thought it would make a 
> good starting 
> point.  I've been doing a fair bit of multiple inheritance 
> lately, and 
> found that the issues can be tricky.
> 
> - Donn Denman
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Dev mailing list
> Dev at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/dev
> 
> 
> End of Dev Digest, Vol 10, Issue 20
> ***********************************
>