On 23.09.2009 06:25, Steve Borho wrote: > On Tue, Sep 22, 2009 at 11:11 PM, Steve Borho <st...@borho.org> wrote: >> # HG changeset patch >> # User Steve Borho <st...@borho.org> >> # Date 1253679040 18000 >> # Node ID 86291cc9b5be14fd9245d171b33247bc654d663e >> # Parent 2bfe0921b4cec3f908fe260da66785eddd7477f5 >> history: start integration of sync bar >> >> Offer "90%" of the features of the synchronize tool inside changelog. >> This patch is mostly a UI mockup. The buttons do not work and it lacks >> tooltips. > > As the comment implies, I'm looking for early feedback on the UI.
Looks good, this is the right way to go. > The current working plan is for incoming to always pull incoming > changes into a bundle file, display the incoming changesets in the > viewer, then allow the user to accept or reject the bundle (if the > user quits without making a choice, the changes are implicitly > rejected). Sounds very good. Maybe this could be extended later to add support for bundles in general. Maybe the "pulled csets bundle" could be given an automatic name. Then show that name in the syncbar. Then add a command to changed that "overlayed" bundle. This would support an "exchange bundles" working style. I assume this working style could become more important in the future, given wishes by projects like Python (see the CRLF line endings discussion). > I was kind of worried that the "incoming" changes would have to be in > a separate window pane, ala MQ, but as it turns out Mercurial treats > bundles in a fortuitously strange way. If you are inside the > repository root when you open the bundle, the repository object looks > just like it would if you had pulled from that bundle. This means we > can graph the incoming changesets just like they were applied, and > paint them green or some other color to indicate their status. Excellent. I assume this will be using http://mercurial.selenic.com/wiki/LookingIntoBundles but of course via mercurial API. > I'll probably have to cripple the context menu for those changesets, > but they will otherwise look like normal commits. Makes a lot of sense. History altering operations (mq family) will sure not work. That's fine for bundle overlays. > For outgoing changes, I plan to use a simplified output template to > just dump the list of changeset hashes that would be pushed, then add > that hash list to the treeview data model and have some visual > property depend on the row's hash being in the outgoing list (any > takers? background color, perhaps). Sounds interesting. > The 'Reset Tip' item in the view menu will be renamed to 'Reset > Marks', and it will clear incoming/outgoing markers and the green > colored new rows. Fine by me. > I also plan to use Yuki's new embeddable command dialog and status bar > where possible. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Tortoisehg-develop mailing list Tortoisehg-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
