Community
Participate
Working Groups
Build Identifier: During Ekie's CDO presentation at EclipseCon he talked about how when writing data to a Cloned Repository, the Cloned Repository first contacts the Master Repository and writes the data there before returning. In our use case where we have teams in India and the US, we would like to use a Cloned Repository to help with improving latency. If we have to wait for the Cloned Repository in India to complete writes in the US Master Repository, then there are no latency gains. If the Cloned Repository could be configured to do asynchronous calls to the Master Repository, this would enable us to get the latency gains we are seeking. Reproducible: Always
Of course the main latency gains are availbale for read operations. Asynchronous commits from the clone to the master introduce lots of conceptual and technical problems, e.g. 1) Clients might continue their work, wrongly believing that they base their assumptions on valid state. What are you suggesting should happen, if the async commit to the master fails? 2) Valid and unique IDs for objects can only be assigned by the master. Eventually this constraint can be overcome when we manage to introduce a completely new approach to object identity, one that's based on UUIDs assigned on the client side. I'm inclined to mark this request as WONTFIX, but I want to wait if I hear new arguments ;-)
Rebasing all outstanding enhancements requests to version 4.0
Moving all open enhancement requests to 4.1
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
