Re: [cclan-list] aside from the pangs of history, what about moving ASDF to common-lisp.net

[Robert G. <rpg...@si...>]

Gary King wrote:
> Hey,
> 
>> Actually, I'm rather tired of the current "but it's better" nonsense
>> on version control systems.  I've heard a dozen names now, and most of
>> that crap is hard to maintain and disappears quick to the next-new-kid
>> on the block.  ...
>> Some new tool that will be dead
>> next week makes sure that software dies.
> 
> 
> I agree with your conclusions but not your premises <smile>. Many of  
> the dvcs tools have been around for a long time (in software years),  
> are used by zillions of people and work much better than CVS for lots  
> and lots of use cases. OTOH, I no longer see the point of Subversion  
> since it, at least, is not better enough than CVS.

I'd have to disagree with you here.  I have come to love SVN.  The
ability to move files, the notion that commits are coherent changesets,
rather than onesy-twosy mods to single files that are difficult to
coordinate ex post facto without the aid of tags, and the improvements
to tagging and branching put it head and shoulders above CVS.  And since
the interface is almost identical to CVS's, the changeover involves
little or no training.
> 
> If you do decide to move and do decide to use a DVCS, then I'd vote  
> that we use git (I'm personally a big darcs fan but bit has much  
> greater momentum, is "more" cross-platform and is building a bigger  
> echo-system, ummm, ecosystem.) Other thoughts?

I feel crotchety in the same way GP lisper does, not so much because I
dislike DVCS per se, but because of the babel of DVCS's.  bazaar, git,
arch, darcs, what a pain.  It annoys me when the ratio of the number of
different DVCS's I need to know to the number of packages I actively
modify gets too close to one.  Especially when these things are
significantly more complicated to use than a standard VCS.  If git drove
the rest off the map (or way out in the periphery), then the changeover
would be a lot more appealing....

On a project by project basis, I think it would be nice to achieve the
following level of rationality:  (1) admit that the use of DVCS's come
at a higher cost in terms of complexity (how significant the cost is
depends on the community --- e.g., to linux kernel hackers, the cost
would be essentially zero because it's already been paid); (2) consider
what benefit a DVCS offers in exchange for the higher complexity cost
and (3) roughly speaking, subtract (1) from (2), and use that to inform
the decision.

cheers,
r