John, On Mon, 2008-11-10 at 06:11 +0000, John Spackman wrote: [ . . . ] > >Isn't this whole Subversion centralism problem solved by using a DVCS > >such as Bazaar, or Git -- and soon, I gather, Mercurial. > > Yes, kind of - I've only recently come across Git and the concept of DVCS > but it was my intention to look at using a DVCS for this.
Bazaar is probably easier for Subversion users to get used to as the command set is more aligned with that of Subversion. (The same goes for Mercurial, but it's Subversion interworking is not yet usable for production working as far as I know.) > But DVCS "only" does source code - setting up a seperate branch only works > if the community at large see the new branch, whereas the Commons group are > considering marking Jelly as "No Longer Maintained" and moving the > repository out of the main branch. I tend to use Launchpad as a place to store Bazaar branches where the host of the Subversion repository cannot support Bazaar. GitHub seems to be the place to store a Git repository in a similar circumstance. A word of warning: Using Bazaar or Git as a Subversion client is not the same as using them as fully-fledged DVCS. The need to rebase so as to remain consistent with the Subversion repository means that many of the aspects of workflow of using DVCS have to be amended. A Bazaar branch of a Subversion repository or a Git clone of a Subversion repository must always be treated as a view on the Subversion repository and not used as a free standing branch/repository. <light-marketing> If anyone is in Oxford, UK 2009-04 then you might think about attending the ACCU 2009 conference. Jim Hague, Time Penhey and myself are doing a session on DVCS. </light-marketing> > From my point of view, I would only want to perform a public branch with the > endorsment of the Commons team; IMHO it's important for new and existing > users to see a future for the project, and for there to be a link from the > official Commons website to the federated Jelly site. The original > downloads would remain for backward compatability, but the Commons site > would clearly refer users onto the new site for upgrades and future > development. I guess I am in the "XML is a data specification language and has no right having a computational model, that's what dynamic languages like Groovy, Python and Ruby are for." camp, so I don't see the demise of Jelly as a problem. Of course graceful demise is entirely appropriate. The question I have is whether putting effort into maintaining a demising system is worth it compared to putting that effort into transferring to a different (more appropriate, in my view) technology for dealing with the problem. There are some very nice candidates for Ant and Maven replacements out there: Gant, Gradle and Buildr to name the obvious trio. (Disclosure: I work on Gant and Gradle :-) These provides for scripting rather than having to create a plugin. -- 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
