Menu
▾
▴
opensync-devel — The place to coordinate the development of OpenSync
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(9) |
Apr
(84) |
May
(18) |
Jun
(12) |
Jul
(6) |
Aug
(7) |
Sep
(10) |
Oct
(31) |
Nov
(59) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(53) |
Feb
(15) |
Mar
(43) |
Apr
(40) |
May
(63) |
Jun
(142) |
Jul
(54) |
Aug
(31) |
Sep
(30) |
Oct
(39) |
Nov
(36) |
Dec
(64) |
| 2007 |
Jan
(128) |
Feb
(261) |
Mar
(156) |
Apr
(127) |
May
(76) |
Jun
(131) |
Jul
(83) |
Aug
(124) |
Sep
(83) |
Oct
(88) |
Nov
(180) |
Dec
(90) |
| 2008 |
Jan
(86) |
Feb
(93) |
Mar
(117) |
Apr
(104) |
May
(65) |
Jun
(35) |
Jul
(38) |
Aug
(111) |
Sep
(58) |
Oct
(33) |
Nov
(102) |
Dec
(194) |
| 2009 |
Jan
(193) |
Feb
(74) |
Mar
(111) |
Apr
(77) |
May
(31) |
Jun
(20) |
Jul
(1) |
Aug
(3) |
Sep
(57) |
Oct
(125) |
Nov
(50) |
Dec
(3) |
| 2010 |
Jan
(26) |
Feb
(5) |
Mar
(13) |
Apr
(3) |
May
(3) |
Jun
(12) |
Jul
(27) |
Aug
(47) |
Sep
(105) |
Oct
(53) |
Nov
(34) |
Dec
(21) |
| 2011 |
Jan
(115) |
Feb
(17) |
Mar
|
Apr
(6) |
May
(16) |
Jun
(15) |
Jul
(85) |
Aug
(21) |
Sep
(13) |
Oct
(12) |
Nov
(28) |
Dec
(23) |
| 2012 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(5) |
Jul
(5) |
Aug
(31) |
Sep
(8) |
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(33) |
Sep
(9) |
Oct
(10) |
Nov
(2) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
| 2016 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Paul E. <blu...@bl...> - 2011-07-31 16:08:26
|
Chris Frey wrote: > My repo.or.cz repo has this latest history now. Chris, I can't see your opensync-cdf repository on repo.or.cz anymore - did you move it? Cheers, Paul ----- Paul Eggleton Intel Open Source Technology Centre |
|
From: Juergen L. <jue...@gm...> - 2011-07-30 21:23:53
|
On Sat, Jul 23, 2011 at 02:15:24AM -0400, Chris Frey wrote: (...) > The repo is here, with 65 commits over the past week and a half: > > http://repo.or.cz/w/opensync/opensync-cdf.git > > > So far, all my tests have been with file-sync and mock-sync. Next on > the agenda is to slowly work through the binary-meta tree, and test > those plugins with valgrind as well. Hopefully opensync will become > bulletproof soon. :-) On fedora 14 I get The following tests FAILED: 39 - filter_destobjtype_delete (Failed) 107 - engine_sync_read_write_stress (Failed) 152 - engine_error_get_changes_disconnect_error (Failed) |
|
From: Juergen L. <jue...@gm...> - 2011-07-30 20:39:40
|
On Fri, Jul 22, 2011 at 06:40:37PM -0400, Chris Frey wrote: (...) > I've noticed in your ldap plugin code, you free this memory with > calls to xmlFree(), which is very correct, but plugins shouldn't > have to know this. This change will affect you. Done. > Also, I notice that you make much use of valgrind in your testing. > I've been fixing a lot of memory leaks in opensync in the above > git repo. If you'd like to give it a try and report back if you > see any improvement, that would be great. Yes, of course. Right now I run the tests without valgrind, and I face some unexpected issues. Anyway - great to see some progress in libopensync. Thank you very much, indeed. Bye, bye Juergen |
|
From: harish b. <har...@gm...> - 2011-07-29 06:15:35
|
Thank you very much. Have a nice day, Harish |
|
From: Chris F. <cd...@fo...> - 2011-07-29 06:07:33
|
On Fri, Jul 29, 2011 at 10:45:00AM +0530, harish badrinath wrote: > Hello, > > Firstly thanks for the quick answer. Does libopensyc provide any > default fallback transport mechanism (between two "networked" nodes) > /marshalling implementation. How is the message passing between two > remote nodes handled (would using AMQP/something similar be a > necessity in this situation ??) > > > +------------------------------+ > > | Machine running | > > | Opensync | > > | / \ | > > | / \ | > > | / \ | > > | / \ | > > | Plugin Plugin | > > +------/----------------\------+ > > / \ > > / \ > > +----------+ +-----------+ > > | Server 1 | | Server 2 | > > +----------+ +-----------+ Opensync itself only concerns itself with communicating with its plugins. It does that by direct procedure calls, in a threated setup, or it can run each plugin as a separate process. If run as a separate process, it uses it's own message handling / IPC / marshalling code to pass messages back and forth to those plugins. In theory it should be possible to run a plugin on another machine than the opensync engine is running on, but I've never done it. The marshalling code uses a read/write style, so this could be done over TCP, if it's not already doing it that way. :-) I'd have to study the code more to know for sure. As for the plugins, they can communicate with their data source any way they like. It could be through a library (such as accessing Evolution data), or direct filesystem access (file-sync), or through libsyncml (currently has some issues, as I understand), or via USB (Blackberry sync talks to the device this way) or some other method. There is no requirement for AMQP... if you want opensync to sync something unusual, you just need to write your own plugin, using opensync's API. The engine asks each plugin what changed in their data source, handles any conflicts, and passes new data back down to the plugins that need updating. From the plugin's point of view, it's all handled by C callbacks. - Chris |
|
From: harish b. <har...@gm...> - 2011-07-29 05:15:06
|
Hello, Firstly thanks for the quick answer. Does libopensyc provide any default fallback transport mechanism (between two "networked" nodes) /marshalling implementation. How is the message passing between two remote nodes handled (would using AMQP/something similar be a necessity in this situation ??) > +------------------------------+ > | Machine running | > | Opensync | > | / \ | > | / \ | > | / \ | > | / \ | > | Plugin Plugin | > +------/----------------\------+ > / \ > / \ > +----------+ +-----------+ > | Server 1 | | Server 2 | > +----------+ +-----------+ > > > Hope that helps, It helped a lot :) Harish |
|
From: Chris F. <cd...@fo...> - 2011-07-29 00:23:37
|
On Thu, Jul 28, 2011 at 06:30:02PM +0530, harish badrinath wrote:
> Hello,
>
> I have a question and i don?t know if it makes sense. Please do
> correct me, if i am wrong.
>
> Can you use libopensync along with zeromq/rabbitmq (rabbitmq is a AMQP
> protocol implementation with zeromq being AFAIK loosely based on AMQP)
> to syncornize data with another server that uses liopensync to
> synchronize random data ??
>
> Or is it better to use libsyncml to sync arbitary binary data some
> media like ethernet.
Not sure if this is the best answer, but for syncing random binary blobs
of data, you could start with something like the file-sync plugin and
make it do what you wanted.
I think your mental picture of opensync might be a bit off. If I read
you correctly, you're viewing opensync like this:
+---------------------+ +-----------------------+
| Server running |<----Sync----->| Server running |
| opensync | | opensync |
+---------------------+ +-----------------------+
When in reality, it's more like this:
+------------------------------+
| Machine running |
| Opensync |
| / \ |
| / \ |
| / \ |
| / \ |
| Plugin Plugin |
+------/----------------\------+
/ \
/ \
+----------+ +-----------+
| Server 1 | | Server 2 |
+----------+ +-----------+
Servers, in this context, can be cell phones or actual servers running
some service that the plugins connect to. Of course, the "machine
running opensync" may in fact be one of the servers.
Hope that helps,
- Chris
|
|
From: harish b. <har...@gm...> - 2011-07-28 13:00:08
|
Hello, I have a question and i don’t know if it makes sense. Please do correct me, if i am wrong. Can you use libopensync along with zeromq/rabbitmq (rabbitmq is a AMQP protocol implementation with zeromq being AFAIK loosely based on AMQP) to syncornize data with another server that uses liopensync to synchronize random data ?? Or is it better to use libsyncml to sync arbitary binary data some media like ethernet. Thanks, Harish |
|
From: Chris F. <cd...@fo...> - 2011-07-25 22:24:10
|
On Sun, Jul 24, 2011 at 10:53:51PM +0100, Paul Eggleton wrote: > Hrm, I think I was going by your earlier comments; that's as far back as > my history goes as well. [...] > As of about 5 minutes ago, yes: > > https://github.com/bluelightning/opensync Our history was identical, except for the commiter information. I've run some checks on the repo, and rebased my work on top of your history which includes the commiter information, and then ran some checks again to make sure. I also changed the commit log entries to match the new SHA1 history. I can't promise to do this for all the plugins, but at least opensync itself has been updated. :-) My repo.or.cz repo has this latest history now. - Chris |
|
From: Michael B. <mb...@gm...> - 2011-07-25 10:29:42
|
On Sun, Jul 24, 2011 at 06:27:38PM -0400, Chris Frey wrote: > On Sun, Jul 24, 2011 at 10:53:51PM +0100, Paul Eggleton wrote: > > > How far back does your repo go? My earliest commits from SVN are: > > > > Hrm, I think I was going by your earlier comments; that's as far back as > > my history goes as well. > > My understanding and my explanation were likely lacking. :-) > > There's a truly huge commit in my repo at: > > commit 6c79ce53bd3dd15b60e51262fd02109c172d5bfa > Author: dgollub <dgollub@53f5c7ee-bee3-0310-bbc5-ea0e15fffd5e> > Date: Mon Feb 12 12:25:19 2007 +0000 > > Moved dev-branch to trunk... > Time to work on 0.30 ;) > > > git-svn-id: http://svn.opensync.org/trunk@1732 53f5c7ee-bee3-0310-bbc5-ea0e1 > 5fffd5e > > > This is the commit where the history of many files suddenly "ends". > But it seems to me that there should be history for some of those > files from before that. > > I'm assuming that "dev-branch" is where this work occurred, and it > was all merged in at once, and so some of these files appear suddenly, > "fully formed". > > I'm not sure if it is worth trying to extract that dev-branch from SVN, > since we can have an old read-only SVN repo for historical reference > even after the move to git. > > But even so, it might be interesting to do just a git-svn clone of > the dev-branch only, and then add that as a historical git branch > for reference. Honestly, I do not think this is time worth spent right now. If there were tons of developers with loads of time on their hands, it would certainly be worthwhile, but at this point, just doing a halfway sane migrations followed by continued development looks like a better investment of developer time to me. >From the sidelines, Michael |
|
From: Chris F. <cd...@fo...> - 2011-07-24 22:34:07
|
On Sun, Jul 24, 2011 at 10:53:51PM +0100, Paul Eggleton wrote:
> > How far back does your repo go? My earliest commits from SVN are:
>
> Hrm, I think I was going by your earlier comments; that's as far back as
> my history goes as well.
My understanding and my explanation were likely lacking. :-)
There's a truly huge commit in my repo at:
commit 6c79ce53bd3dd15b60e51262fd02109c172d5bfa
Author: dgollub <dgollub@53f5c7ee-bee3-0310-bbc5-ea0e15fffd5e>
Date: Mon Feb 12 12:25:19 2007 +0000
Moved dev-branch to trunk...
Time to work on 0.30 ;)
git-svn-id: http://svn.opensync.org/trunk@1732 53f5c7ee-bee3-0310-bbc5-ea0e1
5fffd5e
This is the commit where the history of many files suddenly "ends".
But it seems to me that there should be history for some of those
files from before that.
I'm assuming that "dev-branch" is where this work occurred, and it
was all merged in at once, and so some of these files appear suddenly,
"fully formed".
I'm not sure if it is worth trying to extract that dev-branch from SVN,
since we can have an old read-only SVN repo for historical reference
even after the move to git.
But even so, it might be interesting to do just a git-svn clone of
the dev-branch only, and then add that as a historical git branch
for reference.
- Chris
|
|
From: Paul E. <blu...@bl...> - 2011-07-24 21:53:57
|
Chris Frey wrote: > On Sun, Jul 24, 2011 at 12:52:30PM +0100, Paul Eggleton wrote: >> I guess for me as a Git traditionalist I would prefer to have all the >> history there if possible, or at the very least have the author >> information correct. > >> To that end I did some detective work and came up >> with the author mapping and successfully converted over the repository >> again (well, as far as I can tell) - the only author I was missing was >> "marka", but that person was only the direct author of one commit. In >> any >> case it should be easy to replay your commits on top of the newly >> converted repo if we decide to go this way. > > How far back does your repo go? My earliest commits from SVN are: Hrm, I think I was going by your earlier comments; that's as far back as my history goes as well. > I can rebase my changes if needed. It will take some editing, since > I referred to commit IDs in my tree, which will change with a new SVN > conversion. > > Is your repo available online? As of about 5 minutes ago, yes: https://github.com/bluelightning/opensync Cheers, Paul ----- Paul Eggleton Intel Open Source Technology Centre |
|
From: Paul E. <blu...@bl...> - 2011-07-24 21:50:05
|
Chris Frey wrote: > On Sun, Jul 24, 2011 at 04:36:06PM -0400, Chris Frey wrote: >> Peter: speaking of grabbing from SVN, could you share your list of >> authors >> you used for the git conversion? And perhaps even the command line you >> used. :-) > > Ahem, that should read "Paul" sorry :-) No matter, I shall now rob Peter to pay Paul. ;) The authors list I used is as follows: ------- snip --------- abauer = Armin Bauer <arm...@op...> abaumann = Andrew Baumann <an...@cs...> anirudh = Anirudh Ramesh <aba...@ab...> mbanck = Michael Banck <mb...@de...> azrael = Armin Bauer <az...@de...> bellmich = Michael Bell <mic...@we...> birme = Jonas Birmé <jon...@gm...> bricks = Bjoern Ricks <bjo...@go...> canbus = Ulrich Unterhinninghofen <ulr...@tu...> cdfrey = Chris Frey <cd...@fo...> cstender = Christopher Stender <ope...@ch...> denisq = Quentin Denis <que...@gm...> dfriedrich = Daniel Friedrich <dan...@op...> dgollub = Daniel Gollub <go...@b1...> drzeus = Pierre Ossman <drz...@dr...> duwe = Torsten Duwe <du...@ls...> ehabkost = Eduardo Habkost <eha...@ra...> fejj = Jeffrey Stedfast <fe...@no...> fm = Felix Möller <fe...@de...> friedrich.beckmann = Friedrich Beckmann <fri...@gm...> gcobb = Graham Cobb <g+o...@co...> Graham Cobb = Graham Cobb <g+o...@co...> halton = Halton Huo <hal...@su...> henrik = Henrik Kaare Poulsen <he...@ka...> ianmartin = Ian Martin <ian...@ca...> jerryyu = Jerry Yu <jij...@su...> JimLi = Jim Li <ji...@su...> leoboiko = Leonardo Boiko <leo...@co...> marka = marka <marka> markellis = Mark Ellis <ma...@mp...> mjahn = Matthias Jahn <jah...@fr...> mkoller = Martin Koller <m.k...@su...> paule = Paul Eggleton <blu...@bl...> prahal = Alban Browaeys <pr...@ya...> samm = Alex Samorukov <sa...@os...> savago = Adenilson Cavalcanti <cav...@gm...> teprrr = Teemu Rytilahti <tp...@d5...> tokoe = Tobias Koenig <to...@kd...> tuju = Juha Tuomala <tu...@ik...> twogood = David Eriksson <tw...@us...> ------- snip --------- As far as command lines went it was just: git svn clone http://svn.opensync.org/trunk --authors-file=authors.txt ----- Paul Eggleton Intel Open Source Technology Centre |
|
From: Chris F. <cd...@fo...> - 2011-07-24 20:43:44
|
On Sun, Jul 24, 2011 at 04:36:06PM -0400, Chris Frey wrote: > Peter: speaking of grabbing from SVN, could you share your list of authors > you used for the git conversion? And perhaps even the command line you > used. :-) Ahem, that should read "Paul" sorry :-) - Chris |
|
From: Chris F. <cd...@fo...> - 2011-07-24 20:42:32
|
On Sun, Jul 24, 2011 at 04:06:14AM -0700, Emanoil Kotsev wrote: > So the whole thread can be understood as the latest and greatest is > currently in your git repo. Yes. I will aim to keep my repo as the latest and greatest, until we have a spot for it on opensync.org. Which will hopefully happen soon. > Can't you host git in opensync.org - like svn now. The admins are working on it. :-) > I am planning to fix few things in the akonadi-plugin and retest, > when I have time in the near feature, so might be a good idea to start > with the updated code. I would appreciate all the testing you can give. If you like, you can login to repo.or.cz and make your own git fork of my akonadi-sync plugin here: http://repo.or.cz/w/opensync/akonadi-sync-cdf.git Or you can continue committing to SVN for now and I can grab your changes from there. If you put your changes elsewhere, please post to the list so I can keep my repos up to date. Peter: speaking of grabbing from SVN, could you share your list of authors you used for the git conversion? And perhaps even the command line you used. :-) - Chris |
|
From: Chris F. <cd...@fo...> - 2011-07-24 20:35:13
|
On Sun, Jul 24, 2011 at 12:52:30PM +0100, Paul Eggleton wrote:
> I guess for me as a Git traditionalist I would prefer to have all the
> history there if possible, or at the very least have the author
> information correct.
> To that end I did some detective work and came up
> with the author mapping and successfully converted over the repository
> again (well, as far as I can tell) - the only author I was missing was
> "marka", but that person was only the direct author of one commit. In any
> case it should be easy to replay your commits on top of the newly
> converted repo if we decide to go this way.
How far back does your repo go? My earliest commits from SVN are:
commit 4752eefa898e9b638c4b72214e4f786420b69518
Author: azrael <azrael@53f5c7ee-bee3-0310-bbc5-ea0e15fffd5e>
Date: Tue Nov 30 20:16:17 2004 +0000
Made osync_debug available to plugins
new random_modify and delete function
git-svn-id: http://svn.opensync.org/trunk@2 53f5c7ee-bee3-0310-bbc5-ea0e15fffd5e
commit 705bf81d7a715301dd2d21613b95b382f13bbc59
Author: azrael <azrael@53f5c7ee-bee3-0310-bbc5-ea0e15fffd5e>
Date: Tue Nov 30 19:32:59 2004 +0000
sasd
git-svn-id: http://svn.opensync.org/trunk@1 53f5c7ee-bee3-0310-bbc5-ea0e15fffd5e
I can rebase my changes if needed. It will take some editing, since
I referred to commit IDs in my tree, which will change with a new SVN
conversion.
Is your repo available online?
- Chris
|
|
From: Paul E. <blu...@bl...> - 2011-07-24 11:52:36
|
Chris Frey wrote: > I'm currently operating under the assumption that the "switch to git" > has already happened. :-) I have some time to work on opensync, and so > I've moved all my work there. > > The only thing that remains is finding an official git repo for people > to go to for official releases. Git is distributed, so it is inevitable > that people will have their own repos all over the globe. That is a good > thing. But we also need one place to point people to for the "latest and > greatest". > > For now, my opensync-cdf.git repo is that repo. And I am determined to > keep it up to date and to try to respond to anyone who asks questions > about it, or submits patches to it. I plan to merge quickly if at all > possible. I guess for me as a Git traditionalist I would prefer to have all the history there if possible, or at the very least have the author information correct. To that end I did some detective work and came up with the author mapping and successfully converted over the repository again (well, as far as I can tell) - the only author I was missing was "marka", but that person was only the direct author of one commit. In any case it should be easy to replay your commits on top of the newly converted repo if we decide to go this way. Daniel, what do you think? Can we push an official git repo somewhere? Cheers, Paul ----- Paul Eggleton Intel Open Source Technology Centre |
|
From: Emanoil K. <del...@ya...> - 2011-07-24 11:06:20
|
Hi, Chris, sounds like you've did such a great work :-) thanks for that So the whole thread can be understood as the latest and greatest is currently in your git repo. Can't you host git in opensync.org - like svn now. I am planning to fix few things in the akonadi-plugin and retest, when I have time in the near feature, so might be a good idea to start with the updated code. It's still that syncml is not working with all the recent devices and the various SyncML specs. kind regards --- On Sat, 7/23/11, Chris Frey <cd...@fo...> wrote: > From: Chris Frey <cd...@fo...> > Subject: Re: [Opensync-devel] Breakthrough: all opensync library tests pass > To: "Paul Eggleton" <blu...@bl...> > Cc: ope...@li... > Date: Saturday, July 23, 2011, 11:34 PM > On Sat, Jul 23, 2011 at 11:54:37AM > +0100, Paul Eggleton wrote: > > I'm wondering, should OpenSync consider moving over to > Git from svn? This > > was discussed a while ago and at the time it was felt > that it might delay > > things even further, however, given the pace of > development over the last > > few years I'm not sure it could do any harm and might > actually do some > > good. I quite like Git myself, and moving to it would > increase my interest > > level in contributing again (especially as you seem to > be active) and it > > certainly makes sense IMHO to have everyone working > out of the same VCS. > > I'm currently operating under the assumption that the > "switch to git" > has already happened. :-) I have some time to work on > opensync, and so > I've moved all my work there. > > The only thing that remains is finding an official git repo > for people > to go to for official releases. Git is distributed, > so it is inevitable > that people will have their own repos all over the > globe. That is a good > thing. But we also need one place to point people to > for the "latest and > greatest". > > For now, my opensync-cdf.git repo is that repo. And I > am determined to > keep it up to date and to try to respond to anyone who asks > questions > about it, or submits patches to it. I plan to merge > quickly if at all > possible. > > When there is an official repo, I'd be happy to push my > repo there as a > starting point. > > - Chris > > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual > property that > has been used successfully in hundreds of IBM storage > optimization engage- > ments, worldwide. Store less, Store more with what > you own, Move data to > the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel > |
|
From: Chris F. <cd...@fo...> - 2011-07-23 21:50:01
|
On Sat, Jul 23, 2011 at 12:55:00PM +0200, Daniel Gollub wrote: > * maybe some format specification requires that this specific format > contains the _corect_ UID. So the data of the change can be modified > in a format specific way to update the UID to the new generated UID. > E.g. the file format is using that. The File format structure uses > the path as UID. The path structure member gets updated in this function. [description snipped] Huge thanks! > We might should improve this description and of OSyncFormatDuplicateFunc. I plan to go over this email again and add comments through the code to make this clearer in the future. Thanks again! - Chris |
|
From: Chris F. <cd...@fo...> - 2011-07-23 21:40:56
|
On Sat, Jul 23, 2011 at 11:54:37AM +0100, Paul Eggleton wrote: > I'm wondering, should OpenSync consider moving over to Git from svn? This > was discussed a while ago and at the time it was felt that it might delay > things even further, however, given the pace of development over the last > few years I'm not sure it could do any harm and might actually do some > good. I quite like Git myself, and moving to it would increase my interest > level in contributing again (especially as you seem to be active) and it > certainly makes sense IMHO to have everyone working out of the same VCS. I'm currently operating under the assumption that the "switch to git" has already happened. :-) I have some time to work on opensync, and so I've moved all my work there. The only thing that remains is finding an official git repo for people to go to for official releases. Git is distributed, so it is inevitable that people will have their own repos all over the globe. That is a good thing. But we also need one place to point people to for the "latest and greatest". For now, my opensync-cdf.git repo is that repo. And I am determined to keep it up to date and to try to respond to anyone who asks questions about it, or submits patches to it. I plan to merge quickly if at all possible. When there is an official repo, I'd be happy to push my repo there as a starting point. - Chris |
|
From: Chris F. <cd...@fo...> - 2011-07-23 21:36:38
|
On Sat, Jul 23, 2011 at 03:27:51PM +0200, Daniel Gollub wrote:
> On Saturday, July 23, 2011 12:54:37 PM Paul Eggleton wrote:
> > I tried to test it but unfortunately the version from the Git repo seems
> > to suffer from some kind of CMake path problem - it can't find some CMake
> > modules (e.g. glib2). I've verified OpenSync from svn finds them OK on the
> > same machine.
>
> Same here. I just copied the CMake modules from the opensync SVN repo and
> adapted the CMakeLists.txt so CMAKE_MODULE_PATH points to it.
>
> Chris, does your installed cmake version really contain all those cmake
> modules we have written in the past?
>
> Or do i miss some git submodule magic?
Sorry guys, I should have included this in the original message.
The opensync library is cloned with:
git clone git://repo.or.cz/opensync/opensync-cdf.git
The cmake-modules repo is cloned with:
git clone git://repo.or.cz/opensync/cmake-modules-cdf.git
Then I run cmake with the following switch:
-DCMAKE_MODULE_PATH="/path/to/cmake-modules"
Some background info:
My goal is to have one tree that can compile everything all at once.
This is what I call 'binary-meta'. All my git repos to achieve this
end can be found in the 'forks' list at the bottom of this web page:
http://repo.or.cz/w/opensync.git
"opensync.git" is the git mirror Daniel created earlier. I just created
forks off of that project for each plugin and library repo. The nice
thing about repo.or.cz is that anyone can easily create their own fork
as well. A fork is just another git repo containing the same tree in
a different repo. This allows people to collaborate more easily.
The binary-meta repo does the cmake stuff behind the scenes, and uses git
submodules to reference all of the other git repos I'm working on, in order
to build them all at once, either on a source level, or into binary packages.
There is documentation in the README in that repo, as well as in the top level
Makefile. It is a work in progress, but it does work enough to be useful
right now.
If you have more questions, please ask!
Thanks,
- Chris
|
|
From: Daniel G. <go...@b1...> - 2011-07-23 13:28:06
|
On Saturday, July 23, 2011 12:54:37 PM Paul Eggleton wrote: > Chris Frey wrote: > > I did a test run on opensync tonight, using my git repo, and for the > > first time to my memory, in all my experience with opensync, all > > the tests pass for me. > > Great work! > > I tried to test it but unfortunately the version from the Git repo seems > to suffer from some kind of CMake path problem - it can't find some CMake > modules (e.g. glib2). I've verified OpenSync from svn finds them OK on the > same machine. Same here. I just copied the CMake modules from the opensync SVN repo and adapted the CMakeLists.txt so CMAKE_MODULE_PATH points to it. Chris, does your installed cmake version really contain all those cmake modules we have written in the past? Or do i miss some git submodule magic? Best Regards, Daniel -- Daniel Gollub Linux Consultant & Developer Tel.: +49-160 47 73 970 Mail: go...@b1... B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 |
|
From: Paul E. <blu...@bl...> - 2011-07-23 11:15:11
|
Chris Frey wrote: > I did a test run on opensync tonight, using my git repo, and for the > first time to my memory, in all my experience with opensync, all > the tests pass for me. Great work! I tried to test it but unfortunately the version from the Git repo seems to suffer from some kind of CMake path problem - it can't find some CMake modules (e.g. glib2). I've verified OpenSync from svn finds them OK on the same machine. > Hopefully from now on, we can keep opensync in this good shape. And > improve it. There are more corner cases, I'm sure, that valgrind can > catch. > > The repo is here, with 65 commits over the past week and a half: > > http://repo.or.cz/w/opensync/opensync-cdf.git I'm wondering, should OpenSync consider moving over to Git from svn? This was discussed a while ago and at the time it was felt that it might delay things even further, however, given the pace of development over the last few years I'm not sure it could do any harm and might actually do some good. I quite like Git myself, and moving to it would increase my interest level in contributing again (especially as you seem to be active) and it certainly makes sense IMHO to have everyone working out of the same VCS. Cheers, Paul ----- Paul Eggleton Intel Open Source Technology Centre |
|
From: Daniel G. <go...@b1...> - 2011-07-23 10:55:14
|
On Saturday, July 23, 2011 12:46:03 AM Chris Frey wrote: > While fixing leaks, I ran across the following function in the xmlformat > plugin: > > http://repo.or.cz/w/opensync/xmlformat-cdf.git/commitdiff/d6bf4461281d96bfe > b4bc593a087c04c6e232d3f > > I've removed all the dead code (which contained a leak), but while it looks > correct, and the sync continues to work without that dead code, it looks > kinda odd. Call of this duplicate is actually a quite rare event IIRC. > > I just wanted to confirm: is is true that the duplicate callback is only > for duplicating the UID? Why is there an output/outsize mechanism involved > in that case? Actually it's not only about duplicating and changing the UID to some format specific UID format. > > How else can the duplicate callback be used? It has two more functions: * maybe some format specification requires that this specific format contains the _corect_ UID. So the data of the change can be modified in a format specific way to update the UID to the new generated UID. E.g. the file format is using that. The File format structure uses the path as UID. The path structure member gets updated in this function. * the format duplicate function can decided if this change needs to be written to the device or not by setting *dirty = TRUE. AFAIK if have not yet seen any format / sync protocol which has already some logic to avoid that a duplicated entry needs to be transfered. Note: the change object/data which get passed to this function is already a duplicate. The change got cloned by osync_change_clone() earlier and this function just allows to make the required changes to make a 1:1 clone to a syncable "duplicated" change. Otherwise things break if two changes with the same UID and the same format get synced to a member/device. The big picture or purpose of this function is this: osync_change_duplicate() gets involved by osync_mapping_engine_duplicate() which gets called to solve a conflict. There are several ways in OpenSync to solve sync conflict (changes which are SIMILAR but not the SAME - e.g. on a slow-sync). You can chosse between: * OSYNC_ENGINE_SOLVE_CHOOSE user selects which change to pick - or preconfigured: always "winning" device * OSYNC_ENGINE_SOLVE_IGNORE ignore the conflict temporarily until next sync (not supported by all syncing plugins, only those which are able to "read" single entries which haven't changed - plugin "sync" function) * OSYNC_ENGINE_SOLVE_USE_LATEST use the most recent modified change (only support if the involved objformats are able to determine the last modification timestamp and if the timestamp of two or more entries is not equal) * OSYNC_ENGINE_SOLVE_DUPLICATE - this is the one in question: if a user modified a change (e.g. a contact entry in the addressbook) on two or more devices at the same time, but not resulting in a same entry (e.g. typo in the new phone number on the other device or telephone number with or without country prefix. Then this solving function is the right for you if you are not sure which change is the correct one. This solving type is always available and safes your day if "solving by ignoring" is not available (because a plugin is involved which doesn't support "solving by ignoring" ) Regarding your fix. The fix looks good. Changing the content of a change is optional in the objformat duplicate() function. Actually the entire objformat duplicate() calls is optional for most format plugins: ---8<-- /** * @brief Sets the duplicate function for an object format * * The duplicate function can be used to duplicate an object in your format. * Duplication does not mean to make two objects out of one, but to change * the uid of the object in such a way that it differs from the original uid. * * Most formats will never need this. * * @param format Pointer to the object format * @param dupe_func The duplicate function to use */ OSYNC_EXPORT void osync_objformat_set_duplicate_func(OSyncObjFormat *format, OSyncFormatDuplicateFunc dupe_func); --->8-- "Most formats will never need this." - the reason for that is that only the "most common" formats which is used for comparing and mapping changes will only require this. So far i only have seen xmlformat-$format and file format as the "common" format which is used to do the comparing/mapping. Those are the only function which have "real" duplicate() function and take at least care about changing the uid. We might should improve this description and of OSyncFormatDuplicateFunc. (I didn't remember all that, i had to read the calling code of the duplicate function) Hope that helps. Best Regards, Daniel -- Daniel Gollub Linux Consultant & Developer Tel.: +49-160 47 73 970 Mail: go...@b1... B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 |
|
From: Chris F. <cd...@fo...> - 2011-07-23 10:41:03
|
On Sat, Jul 23, 2011 at 12:05:19PM +0200, Daniel Gollub wrote:
> Run with G_SLICE=always-malloc
>
> dgollub@marvin:~/projects/opensync-cdf/build/tests> valgrind /home/dgollub/projects/opensync-cdf/build/tests/engine-error
> engine_error_get_changes_disconnect_error
> ==490== Memcheck, a memory error detector
> ==490== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
> ==490== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
> ==490== Command: /home/dgollub/projects/opensync-cdf/build/tests/engine-error engine_error_get_changes_disconnect_error
> ==490==
> Running suite(s): "engine_error"
> ==491== Thread 4:
> ==491== Invalid write of size 4
> ==491== at 0x4E7AF3D: osync_queue_disconnect (opensync_queue.c:1206)
> ==491== by 0x4E4E5FD: osyncClientDisconnectCallback (opensync_client.c:1960)
> ==491== by 0x50FBBD2: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.2800.0)
> ==491== by 0x50FC3AF: ??? (in /lib64/libglib-2.0.so.0.2800.0)
> ==491== by 0x50FCA34: g_main_loop_run (in /lib64/libglib-2.0.so.0.2800.0)
> ==491== by 0x5123465: ??? (in /lib64/libglib-2.0.so.0.2800.0)
> ==491== by 0x749CA3E: start_thread (pthread_create.c:297)
> ==491== Address 0x7c9d228 is 232 bytes inside a block of size 240 free'd
> ==491== at 0x4C2599C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==491== by 0x4E7A287: osync_queue_unref (opensync_queue.c:953)
> ==491== by 0x4E53D06: osync_client_proxy_shutdown (opensync_client_proxy.c:1239)
> ==491== by 0x4E5C421: _osync_engine_finalize_member (opensync_engine.c:749)
> ==491== by 0x4E5E3DD: osync_engine_finalize (opensync_engine.c:1807)
> ==491== by 0x4063F6: engine_error_get_changes_disconnect_error (check_engine_error.c:2907)
> ==491== by 0x6CEFE18: srunner_run_all (in /usr/lib64/libcheck.so.0.0.0)
> ==491== by 0x412548: osync_testsuite (support.c:65)
> ==491== by 0x6F11BFC: (below main) (libc-start.c:226)
Thanks! That's a new one.
In osync_queue_new_threadcom(), connected_queue gets set to opposing
read/write queues, but is not ref'd. I think it was written that way on
purpose, so I'll have to look at it more closely later. For example,
osync_queue_unref() doesn't unref it, it just set it to NULL.
But osync_queue_disconnect() does this:
if (queue->usethreadcom){
queue->connected_queue->connection_closing = TRUE;
}else{
so it either needs a ref, or just a check whether connected_queue is NULL.
Will have to check the others when I have more time.
Thanks,
- Chris
|
90 messages has been excluded from this view by a project administrator.
