|
From: Daniel G. <go...@b1...> - 2010-08-14 00:47:40
|
On Saturday, August 14, 2010 09:09:50 am Chris Frey wrote: > ATTENTION anyone reading this thread: please let me know if this will cause > trouble that I don't foresee. I plan to update at least the opensync SVN > to get rid of its externals if possible, and put all plugins into it. I guess this would break our test automation we have running currently: http://opensync.org/testing/ And so far we only have one single svn:externals - and it's just for the cmake modules. Yeah, it's sad that this breaks git and others ... but the cmake- modules doesn't change that often. Actually we introduced that due to the fact that cmake and it's modules were still in a very early stage of development. So we had to write a couple of cmake modules by our own to find buliding depencies ... i guess some modules find their way already in recent cmake versions which already packaged in recent distribution. So we could think of getting replacing svn:externals by merging the changed modules - if required. How does that sounds to you? You might wanna try this for those repositories you're actively using - e.g. opensync, osynctool(?), google-calendar, file-sync, ... so you can use for those at least a git bridge. Regarding moving all plugins into one repo ... The Distribution packager might not be happy about that ... Since this would be heavy packaging change. Another problem might be the difference licenses. libopensync is LGPLv2 I guess most of the plugins are GPLvX or something else but in most cases not LGPLv ... something which packager might not like as well. I would still prefer to keep plugins out of the opensync directory. Actually i planned to do build testing by ctest and cdash. So i don't have to build-test all plugins by myself. So far only few plugins get build-tested in our cdash/ctest instance. Right now also some magic is required so they get build tasted against latest trunk. A SCM-repo with libopensync and all plugins might would be a solution. Why not just checking out libopensync and all plugins and write some special make target which jumps to the parent directory or special directory where all plugins got checked out? I guess only few developers going to need to build all plugins at the same time. Those who plan to change/break the API. That shouldn't be the case so often ... right? But maybe we can provide all this to you some how without changing the entire SCM? To sum this up: I'm ok with getting rid of cmake-modules svn:extenrals for some plugins and opensync and osynctool and use merge instead. And we should try to get as many of those merged to the cmake project. No SCM change before 0.40 got released. No plugins within opensync/trunk/ Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner Linux Consultant & Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |