[Opensync-devel] SCM changes? (was: Re: Fwd: Google plugin for opensync)

[Daniel G. <go...@b1...>]

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