Strategies for push/merge problem?

[Sean Russell]

On Wednesday 16 July 2008 02:06:21 am Peter Arrenbrecht wrote:
> On Wed, Jul 16, 2008 at 3:35 AM, Sean Russell <hg at ser1.net> wrote:
...
> > example, it is much, much easier to "svn switch" in Eclipse than it is to
> > create an entirely new project, and 90% of the overhead *isn't* in the
> > checking out. It is in walking through the Wizards to create a project. 
> > Shelving lets you re-use a workspace, which is a huge advantage when
> > you're using an IDE.
>
> I use Eclipse extensively. I rely on a small script to initialize new
> clones with the proper Eclipse project files. Then I can either use a

That's a good idea.

> The advantage over shelve is that sometimes my one-liners turn out to
> be just a trifle more complex than that (usually really, as they need
> test support, too), and this makes it easy to go back to them and
> improve, or use mq, or whatever is needed.

Yes.  I'm not entirely comfortable with the MQ workflow, yet.  MQ, for me, is 
mental state that I have to keep track of -- I have to remember that I'm 
working with MQ as I work.  Anything like this distracts me from doing actual 
work, or I forget and make mistakes with it.  I think I just need more 
practice with it.

However, I strongly suspect that you can do with MQ anything you can do with 
shelve, if with more steps.  What I don' understand is why you imply that it 
makes a difference whether what you're doing is a one-liner or a huge 
refactoring.

Shelving with MQ actually isn't too bad, now that I think about it:

* There are changes that have been committed, but haven't been pushed yet.  
   I may not be ready to push those changes.
* There may be work that hasn't been committed yet, that I'm not ready to
   commit.  These are things that I'm going to "shelve," either with the
   shelve plugin or with MQ.  If I were using MQ, this wolud be 3 steps:
   * hg qnew shelf
   * hg qrefresh
   * hg qpop
* After shelving uncommitted work, I branch off the revision that was last
   pushed.  Because I like to reuse working copies, I tend to use 'branch.'
   This involves 3 more steps:
   * hg outgoing
   * hg up -r REV -C
   * hg branch NAME
* Work, commit, work, commit
* Push the changes upstream
* Change back to where I left off, and unshelve my work:
   * hg up -r tip
   * hg qpush
   * hg qdelete shelf

This isn't too onerous; it takes 6 commands to shelve, and three to unshelve.  
This could easily be scripted down to two commands.  

Anyway, I think Roman's team's original problem stemmed from the fact that 
they didn't realize that they'd have to think about how they were going to do 
this before they did it; it wouldn't have been obvious to me that this was 
going to require some prep-work, either.  It _is_ certainly solvable, and all 
of their problems with their workflow avoidable, but it requires knowledge 
that there's some advance (but not troublesome) set-up required before you go 
and perform your one-liner fix.  And they don't have to change their workflow 
to do it.

--- SER