On Wed, 2012-02-29 at 16:13 +0100, Giuseppe Scrivano wrote: > Jeremy Bennett <[email protected]> writes: > > > We are rather going down the route of "git is the answer, now how do we > > change the question to fit the answer". I use SVN, CVS and git > > professionally. They all have their strengths and weaknesses. For every > > expert who marvels at the richness of git, there is a beginner baffled > > by its complexity. The answer is to use the right tool for each job. > > Using git (or any other DVCS) in the same manner as SVN/CVS doesn't > introduce any additional complexity. In a sparse team with developers > not working just on small patches, a DVCS can make the merge phase a lot > easier.
It adds complexity because you are now using two tools, SVN/CVS and git. You need to use SVN/CVS for your upstream commits. The git mirrors for GCC and binutils/gdb/newlib are read only. I'm not arguing against DVCS, for the experienced software engineer they offer huge riches. But for the established project they come with a cost, and for the beginner they are an additional learning burden. Indeed one of my serious beefs against git is the lack of a good introductory tutorial that does not assume you already are familiar with another version control system. > I am not sure nowadays there is a single task where CVS can be a better > choice than git (except maybe a test-suite for CVS). Where the task is addressing a community that is already familiar with CVS. Don't forget the cost to a large project of educating the community in any new tool. Most commercial hardware development teams still fit into this category. Jeremy -- Tel: +44 (1590) 610184 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: [email protected] Web: www.embecosm.com _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
