On Fri, Sep 18, 2009 at 9:52 PM, Yuki KODAMA <endflow....@gmail.com> wrote: > On Sat, Sep 19, 2009 at 11:36, Steve Borho <st...@borho.org> wrote: >> On Fri, Sep 18, 2009 at 12:21 AM, Yuki KODAMA <endflow....@gmail.com> wrote: >>> On Fri, Sep 18, 2009 at 00:04, Steve Borho <st...@borho.org> wrote: >>>> On a side node, I think our update dialog should add --check to the >>>> update command arguments if the --clean checkbox is not checked. The >>>> user is explicitly selecting the revision to update to, and thus they >>>> are aware of any branch hopping that might be necessary. >>> >>> I'm still working on Update dialog. >>> It might be changed drastically, but I'll certainly respect "--check" >>> option. >>> I understood what you said with your changeset <6a83929f6085>. >> >> Actually, my commit was wrong. Specifying --check prevents you from >> doing any update if the working directory is dirty, even if you're not >> switching branches. >> >> So both --clean and --check need to be checkboxes, or we need radio >> buttons with 'force clean', 'check clean', 'allow merge'.. or >> something similar. > > I see, I'll start to work on that. > > BTW, after pulling in synch dialog, it shows bottom bar contained > "Update to branch tip" > button and "Check update" checkbox. I suppose we should turn on "Check > update" > checkbox in default, how about this? > I failed many times at this since I forgot check that checkbox.
Hmm, 'Check Update' probably isn't the best name for it, now that I think about it. '--check' really means 'check if the repo is clean, only then update unconditionally' '--clean' really means' update unconditionally, discarding local changes' neither means 'update and merge local changes, unless it requires a branch change' Three entirely different things. It's beginning to dawn on me that the best approach here is to add some smarts behind the update feature. When the user presses update, we should determine whether the update requires a branch change. If not, then just let it continue. If it does, it should check if the repo is clean. If it's clean, we should add the --check flag for the user so the update succeeds. If it requires a branch change, and the repo is dirty, we should ask the user whether they want to discard changes or offer to open the shelve tool or something. I think this is the approach CuteHg took. Here's the documentation for Mercurial's update command: Update the repository's working directory to the specified revision, or the tip of the current branch if none is specified. Use null as the revision to remove the working copy (like 'hg clone -U'). When the working directory contains no uncommitted changes, it will be replaced by the state of the requested revision from the repository. When the requested revision is on a different branch, the working directory will additionally be switched to that branch. When there are uncommitted changes, use option -C/--clean to discard them, forcibly replacing the state of the working directory with the requested revision. Alternately, use -c/--check to abort. When there are uncommitted changes and option -C/--clean is not used, and the parent revision and requested revision are on the same branch, and one of them is an ancestor of the other, then the new working directory will contain the requested revision merged with the uncommitted changes. Otherwise, the update will fail with a suggestion to use 'merge' or 'update -C' instead. -- Steve Borho ------------------------------------------------------------------------------ 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
