On Jul 9, 2010, at 10:32 AM, Nick Boldt wrote: >> But it appears that Hudson only allows one SCM entry. > > One CVS entry, sure. Or multiple SVN or Git entries. Another reason to > abandon CVS! :)
Oh, I missed that add part. But no SVN + GIT + CVS, I guess. I'm hoping to abandon SVN as well, but o course I"m not in control of other projects. I'll have to find a better solution for my sourceforge projects -- unfortunately Google Labs doesn't support Git. > > Regarding automation and source fetching... I have done some work with > Tycho/Maven as the build engine, supplemented by Ant to do some extra build > magic. (Specific example is that we build some plugins/features for Drools to > wrap the plugins/features that the Drools team does themselves; rather than > rebuild their code, I use Ant to fetch their latest binary build from their > Hudson job, unpack it, and have it available against which to compile our > stuff.) Ideally they'd just publish a p2 repo against we could resolve the > target platform, but for now this works just as well.) You could do the same > to fetch CVS sources if you wanted... but really, moving to SVN or Git would > be an even better idea. :) Yeah, I actually made the decision to use CVS over SVN if you can believe it just because of my experiences with robustness of SVN or lack thereof and because the rest of Modeling was using it..but now, with XText moving to Git I'll likely be following their lead. I am *not* *not* *not* going to get into Maven now, lol. cheers, Miles > > Nick > >> On Jul 8, 2010, at 3:28 PM, Nick Boldt wrote: >> >>> That's pretty much how PDE works... >>> >>> 1. Hudson checks out your code into its job workspace. >>> 2. When changes occur, it kicks a build for you. >>> 3. Then the PDE build fetches sources from map file and you end up with >>> double the source on disk. Hella inefficient. >>> >>> Alternative approach is to have the PDE build use local sources already on >>> disk as fetched by Hudson, rather than having the build provision the >>> sources for you. Athena does this using the localSourceCheckoutDir >>> variable; Bucky prolly has an analoguous approach. >>> >>> There's also the non-PDE approach using Tycho+Maven, which simply builds >>> from the already-available sources in Hudson's workspace. Doesn't support >>> fetching from map file, only from a branch/tag (that is, it'll build >>> whatever Hudson's already fetched). Ideal for CVS, SVN, or Git sources. >>> >>> Nick >>> >>> On 07/08/2010 02:38 PM, Miles Parker wrote: >>>> Hi all, >>>> >>>> I'm wondering how people are setting up SCM WRT Buckminster. >>>> >>>> 1. As I understand things it seems like best practices with Buckminster >>>> would involve pulling everything from Version Control through Buckminster? >>>> 2. Except that the releng site, i.e. rmap, cspec etc.. obviously need to >>>> be there so they need to be bootstrapped into the Hudson workspace, >>>> presumably through Hudson SCM. >>>> 3. And, you want any changes in covered code to trigger an SCM which (I >>>> think?) means bringing all of that stuff over from SCM first. >>>> >>>> 2 and 3 sort of seem to conspire against 1, or am I missing something here. >>>> >>>> Also, I think this might have been asked before, but is there any way to >>>> view the configurations of other projects to see how they've got things >>>> setup? >>>> >>>> cheers, >>>> >>>> Miles_______________________________________________ >>>> dash-dev mailing list >>>> dash-dev@eclipse.org >>>> https://dev.eclipse.org/mailman/listinfo/dash-dev >>> >>> -- >>> Nick Boldt :: http://nick.divbyzero.com >>> Release Engineer :: Eclipse Modeling& Dash Athena >>> _______________________________________________ >>> dash-dev mailing list >>> dash-dev@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/dash-dev >> >> _______________________________________________ >> dash-dev mailing list >> dash-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/dash-dev > > -- > Nick Boldt :: http://nick.divbyzero.com > Release Engineer :: Eclipse Modeling & Dash Athena > _______________________________________________ > dash-dev mailing list > dash-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/dash-dev _______________________________________________ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
