Strategies for push/merge problem?

[Douglas Philips]

On or about 2008 Jul 14, at 9:51 PM, Sean Russell indited:
> My 0.02 cents to solve the one-liner problem: hg shelve:
>
> 	http://www.selenic.com/mercurial/wiki/index.cgi/ShelveExtension

Looks nice, but the announcement is 1.5 years old, and the  
presentation is such that I don't feel very comfortable using it (this  
hack works for me, ymmv). The "ships with Mercurial" badge is very  
comforting, since it tells me the extension is regularly tested. I  
know, marketing, but there you have it. :)

> On Monday 14 July 2008 11:45:08 am Doug Philips wrote:
>>
>> Clones are easy. Why not have a few -clean- spares sitting around,  
>> maybe:
>> "Quick Fixes" and "clean upstream" and so forth.
>
> Well... I tend to get lost when I have a ton of workspaces floating  
> around,
> and I never trust that what they're named actually reflects what's  
> in them.

Names are hard. But, if you have good commit messages, then hg log  
will tell you what's in them. If you don't have good commit  
messages.... <shudder/>

> Can you elaborate on this?  I assume you mean cloning:
>
> 	"main" repo -> Local copy (clean) -> Work copy 1
>
> which means that any work I push back goes to the local copy, which  
> I then
> have to push back to the main repo.  The three step process (commit,  
> fetch,
> push) now becomes a six step process (commit, push, cd, update,  
> fetch, push).

No, I mean:
	"main" repo > local clean copy -> <n> working clones.

Flow is that when I want to get "main" changes, I pull to local clean  
copy, then pull again into whatever working clones I care about.  
Changes get pushed form the working clones to the pushee tree, never  
to local clean copy. Local clean copy exists so that I can <snap  
fingers>clone</snap fingers> to get a fresh tree to do a one-off, or  
whatever.

I'm sure this is described on the Hg wiki somewhere, but I can never  
find it when I go looking, only when I want to find something else. :)


--Doug