Helmut, On Sun, 2008-10-12 at 20:35 -0700, Helmut Denk wrote: [ . . . ] > you may have different constraints in an enterprise-context than in > an open-source-community-context. many decisions have a political > aspect here and the 'prevailing mood' is conservative. for some good > reasons as the ongoing financial-crisis demonstrates ... > > reliebility, saftey, ease of use is much more important than technical > brilliance. esp. ease of use(!) as you may have users/developers that > come from far outside of the java-world. excellent tool-integration is > essential.
The problem with political solutions is that they are often made based on faulty information and prejudice. Also the decision is often based on contradictions that are allowed to be treated as consistent fact. As CTO of OneEighty Software Ltd and through consulting via It'z Interactive Ltd and Concertant LLP, I have direct experience of all the stupidities in the system :-( In terms of number of years in existence, and installed base, Subversion is clearly the winner. So if that is the principle metric the decision is clear. But ease of use is not a good metric for Subversion as a software development tool. Certainly it's GUIs are more developed that those of the DVCS but that is not the only factor in ease of use. You have to match the features to the use cases and workflow. If you want a version filestore then Subversion is excellent -- I recommend it, indeed use it (albeit via Bazaar and Git as client), for this purpose myself. For software development though, branching and merging may be important. If it isn't and all actors are always connected to the Internet then Subversion can be fine. Where Internet connection is not guaranteed or where branching and merging are important then Subversion fails compared to Mercurial, Bazaar and Git. > progressive people have to be careful ... in order to survive. There will always be leaders and followers. Leaders just have to accept that followers follow. Sometimes 10 or 20 years later, which is an eon or two in computing :-) > back to gradle ... how difficult would it be to svn-mirror gradle > in lauchpad ? There already is one. lp:gradle is an automated mirror of the Codehaus Subversion repository. I also have a manually maintained mirror as well (for when the Launchpad automation has a glitch. The next step is to use the Launchpad infrastructure to make Debian and Ubuntu packages of Gradle. > this DVCS-thing really has a potential to drag developers away from > their road-map ... > > be careful ;-) Yes and no. If time spent rearranging infrastructure then causes faster development there is the cross-over point where you start being in activity profit. The trick is to make sure that the rearrangement time is relatively small and that the cross-over point is reached soon. If rearrangement time is lengthy and/or increased productivity means the cross-over time is a long way out, then serious caution is required. -- Russel. ==================================================== Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077
signature.asc
Description: This is a digitally signed message part
