Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Will D. <wi...@wj...>]

Andreas,

I don't have any particular preference.  I use fossil, and like it; git is clearly worth learning, and I've been meaning to do that.  And either will work.

I think the question is, do we want to host it "ourselves", in which case Fossil is the big winner, or do we want to let someone else host it, in which case git is the big winner.

It probably makes sense to adopt whatever is adopted for the Tcl core.

Will

On Feb 14, 2011, at 1:21 PM, Andreas Kupries wrote:

> Hi all you developers of Tcllib, Tklib, BWidget, etc. ..
> 
> You might have noted that the SourceForge CVS was down for two weeks,
> after a hack attack on them.
> 
> This downtime ended last week, allowing us, in principle, to continue 
> development and re-start commits.
> 
> There is however a fly in the soup. Quoting from Jeff's mail to tcl-core
> 
> 	In the interim, SF also let us know that cvs is now considered
> 	a legacy service.
> 
> In other words, the end-of-life of CVS repositories on SF, and maybe in general 
> is on the radar now, and it behooves us, IMHO, to do the transition to 
> something else _now_.
> 
> As such I ask everyone to hold back from commiting anything to any of the 
> projects under tcllib (1) until we have this issue resolved.
> 
> 
> While SourceForge apparently will offer a migration service from CVS to SVN I 
> agree with Jeff that we should transition to a proper DVCS instead.
> 
> Related to the choicce of DVCS is also the issue of hosting, i.e. depending on 
> what our choice of system we have less or more options for hosting.
> 
> Following the discussions on the chat, about the same issue, only for core 
> Tcl/Tk the main contenders are
> 
> 	our own Richard Hipp's "fossil" 	(2),
> 	and the ubiquitous 800lb gorilla "git"	(3)
> 
> From a technical point of view both will do the job, and are pretty much 
> equivalent. Conversion to either should be relatively trivial via "cvs2git" 
> (4), both support the fast-export file-format generated by the converter.
> 
> Non-technical arguments for either are
> 
> *	fossil is small, clean, simple, easy to learn, with the developer part
> 	of the Tcl community, and known to be responsive. Pretty much on call.
> 
> *	git, while not small, and with a steep learning curve, however is
> 	*ubiquitous*, with a much larger community. Students learn it.
> 	Using it means that a GSoC student (for example), can simply be
> 	pointed to the git repository and told to branch.
> 
> *	On the hosting front, using git give us lots of alternatives as:
> 
> 		SourceForge, github, gitorious(sp?), assembla
> 
> *	For fossil we either have to either use the pretty much unknown
> 
> 		chiselapp
> 
> 	or self-host. The latter might actually not be to onerous, given that
> 	fossil comes with a builtin web server. Just needs a box.
> 
> *	Richard has its own comparison and reasons for either at
> 	http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki
> 
> 
> Do I have my own preference ? Yes. And I sincerely hope that I managed to keep 
> it out of the arguments above.
> 
> 
> One last issue. As (1) shows, we have lots of subprojects. Seven. While these 
> are all handled by a single CVS repository directory hierarchy, when going to 
> DVCS we should really split them up, each as their own XXX repository. One of 
> them, tclbench, should possibly even migrate out of the tcllib more to the core 
> itself, given that it is the core whose performance this project is testing.
> 
> Discussion is open.
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (1) Which are
> 	bwidget
> 	mclistbox
> 	tclapps
> 	tclbench
> 	tcllib	(sic)
> 	tklib
> 	widget
> 
> (2)	http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
> (3)	http://www.kernel.org/pub/software/scm/git/docs/git.html
> 
> (4)	In contrast to Tcl/Tk core tcllib does not have vendor branches in the
> 	history AFAIK.
> 
> -- 
> Andreas Kupries
> Senior Tcl Developer
> ActiveState, The Dynamic Language Experts
> 
> P: 778.786.1122
> F: 778.786.1133
> and...@ac...
> http://www.activestate.com
> Get insights on Open Source and Dynamic Languages at www.activestate.com/blog
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel


Will Duquette, OP
will -at- wjduquette dot com  
http://foothills.wjduquette.com/blog