On Wed, Feb 18, 2009 at 5:55 AM, Emmanuel Lecharny <[email protected]>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. Absolutely! > 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. Alex
