On Wed, Feb 18, 2009 at 5:55 AM, Emmanuel Lecharny <email@example.com>
> The separate clear() and revert() operations decouples functionality. TheHaving thought about those methods a bit more, I think that clear()
> 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.
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
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.