directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: ChangeLog + revert, broken , take 2
Date Wed, 18 Feb 2009 14:10:02 GMT
On Wed, Feb 18, 2009 at 5:55 AM, Emmanuel Lecharny <>wrote:

> > The separate clear() and revert() operations decouples functionality.
>  The
> > revertAndClear() operations both couples functionality together.  You
> might
> > find situations where you just need to clear() or just to revert() and
> > sometimes to do both as is the case now.  When we break things down into
> > simpler functions that do one thing and only one thing well then it's
> easier
> > to recombine them to suite different situations.  This may also lead to
> > better interface design.
> Having thought about those methods a bit more, I think that clear()
> and revert() are different.


> Clear() simply remove every entry from the
> server _and_ from the changeLog,

We should also have a clear() overload that takes a revision int parameter
removing everything up to a specific revision.

> when revert() remove entries from the
> server bug logs revert operations into the changeLog.

I don't understand what you mean here by "server bug logs". Can you clarify?

> You can't do a
> revert() followed by a clear(), it's a waste, as everything you will
> write in the changeLog in the revert() method will be erased by the
> clear() method.

You can do a revert(int a) followed by a clear(int a) to bring the server
back to state 'a' and remove any record of changes in the changelog.  This
was the original aim of this email: to remove all the excess operations we
don't really care about due to reverts so that reverts occur faster.  This
is exactly the pattern of revert()/clear() usage you would need to get the
effect you are after.

> So the clear() semantic is : remove everything from server and
> changelog

Just from the changelog.

> up to the latest tag (or up to a specified tag)
> and the revert() semantic is : revert everything from the serve, but
> log the reverted operations in the changeLog. You can revert a revert
> (redo).

Yep we can "revert a revert" which is great for an undo mechanism. Basically
clear would wipe out this history in the log preventing this but some cases
may warrant it.


View raw message