Strategies for push/merge problem?

Sean Russell hg at ser1.net
Tue Jul 15 20:35:20 CDT 2008


On Monday 14 July 2008 10:45:41 pm Douglas Philips wrote:
> > 	http://www.selenic.com/mercurial/wiki/index.cgi/ShelveExtension
>
> Looks nice, but the announcement is 1.5 years old, and the

Actually, local clones pretty much remove the need for shelving.  The main 
advantage for shelving that local clones don't satisfy is when you're using 
an IDE, and setting up a new project is non-trivial.  For 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.

> 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/>

The point being that it takes investigative effort to determine what the 
purpose of any given WC is; this isn't a "jump around among a bunch of 
different local copies."   At least, it isn't for me.

Mind you, I'm a big fan of local copies, but I beyond about three of them, my 
efficiency in using them starts to drop off precipitously.

> 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

Right, what I outlined later in the email.

> 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.

You still have to update the clean copy, or it becomes hopelessly out of date 
rather quickly.  Still, those steps can be done periodically, rather than at 
every push.

--- SER


More information about the Mercurial mailing list