On Thu, 2016-06-30 at 20:53 -0600, Rich Megginson wrote:
> On 06/30/2016 08:14 PM, William Brown wrote:
> > On Thu, 2016-06-30 at 20:01 -0600, Rich Megginson wrote:
> >> On 06/30/2016 07:52 PM, William Brown wrote:
> >>> Hi,
> >>>
> >>> I've been thinking about this for a while, so I decided to dum
On 06/30/2016 08:14 PM, William Brown wrote:
On Thu, 2016-06-30 at 20:01 -0600, Rich Megginson wrote:
On 06/30/2016 07:52 PM, William Brown wrote:
Hi,
I've been thinking about this for a while, so I decided to dump my
thoughts to a document. I think I won't get to implementing this for a
while
On Thu, 2016-06-30 at 20:01 -0600, Rich Megginson wrote:
> On 06/30/2016 07:52 PM, William Brown wrote:
> > Hi,
> >
> > I've been thinking about this for a while, so I decided to dump my
> > thoughts to a document. I think I won't get to implementing this for a
> > while, but it would really help o
On Thu, 2016-06-30 at 14:53 -0700, Noriko Hosoi wrote:
> On 06/30/2016 12:45 AM, Ludwig Krispenz wrote:
> > Hi William,
> >
> > the reason that after a total init the consumer does not have the
> > latest state of the supplier RUV and is receiving updates based on the
> > RUV at start of the tot
On 06/30/2016 07:52 PM, William Brown wrote:
Hi,
I've been thinking about this for a while, so I decided to dump my
thoughts to a document. I think I won't get to implementing this for a
while, but it would really help our server performance.
http://www.port389.org/docs/389ds/design/logging-per
Hi,
I've been thinking about this for a while, so I decided to dump my
thoughts to a document. I think I won't get to implementing this for a
while, but it would really help our server performance.
http://www.port389.org/docs/389ds/design/logging-performance-improvement.html
--
Sincerely,
Will
On 06/30/2016 12:45 AM, Ludwig Krispenz wrote:
Hi William,
the reason that after a total init the consumer does not have the
latest state of the supplier RUV and is receiving updates based on the
RUV at start of the total init is independent of the modrdn problem.
When a supplier is performi
https://fedorahosted.org/389/ticket/48907
https://fedorahosted.org/389/attachment/ticket/48907/0001-Ticket-48907-register-ds-admin-fails-to-find-local-c.patch
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
https://fedorahosted.org/389/ticket/48306
https://fedorahosted.org/389/attachment/ticket/48306/0001-Ticket-48306-perl-module-conditional-test-is-not-con.patch
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
Hi William,
the reason that after a total init the consumer does not have the
latest state of the supplier RUV and is receiving updates based on the
RUV at start of the total init is independent of the modrdn problem.
When a supplier is performing a total init it is still accepting
changes,
10 matches
Mail list logo