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