On Tue, Feb 7, 2012 at 9:23 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Tue, 2012-02-07 at 09:04 +0100, Murray Cumming wrote:
> On Tue, 2012-02-07 at 03:35 +0100, Chris Kühl wrote:
> > Yeah, unfortunately things are not ideal. Have you given any further
> > thought as to how we are going to properly detect conflicting sync
> > sessions? This points getting close that this is going to need to be
> > dealt with. I've not looked into this at length yet. Is there no
> > interface I could use to test that syncs will not conflict?
>
> Nevertheless, it would be nice to punt this to a later patch/branch,
> just so we have some chance to get the current work into master.
I agree. Let's keep the current behavior (only one session can run at a
time) and figure out how to detect non-conflicting sessions later. Don't
bite off more than you can swallow :-)
Ok, I'll reimplement the queue then.
I was thinking that with an interface in place I could actually have
the code in-place that would do the concurrent sessions even if now it
would always return that there is a conflict. For testing that
concurrent sessions do actually work with known, non-conflicting
sources, we could introduce an environment variable that would return
that there is no conflict. That way, as soon a solution is found ofr
finding conflicts, is should just work.
Patrick, you were also mentioning that you'd like to rework the
autosync mechanism. Shall I strip out that functionality from the
server?
Cheers,
Chris