On Wed, Feb 18, 2009 at 5:55 AM, Emmanuel Lecharny <elecharny@apache.org> 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

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

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.