Strategies for push/merge problem?

Sean Russell hg at ser1.net
Mon Jul 14 20:51:39 CDT 2008


On or about 2008-07-14 10:24:13, Roman Kennke inquired:
> Lately a developer in my team who is developing on some code needed to
> get in a quick fix for a problem that was biting everybody else. It was
> a one liner.

My 0.02 cents to solve the one-liner problem: hg shelve:

	http://www.selenic.com/mercurial/wiki/index.cgi/ShelveExtension

Before you start working on a one-liner, shelve everything in your working 
directory (thereby gaining a clean workspace), do the one liner, commit, 
pull, merge, push, then unshelve.

You can do the same thing with patch queues, but the shelving is a pretty 
common concept.  In practice, though, local cloning is a pretty good 
substitute for shelving.

The hardest thing for me to get over when using Mercurial was my fear of 
cloning.  I compare it to a fear of branching and tagging in Subversion -- 
once you realize just how fast and cheap copies in SVN are, you (or, at 
least, I) tend to use them with abandon.  Same with local clones in 
Mercurial, on Linux, at least.

On Monday 14 July 2008 11:45:08 am Doug Philips wrote:
> >- Try to always have a clean workspace without uncommitted changes
> > (impossible I think, but you can try).
>
> 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.

> > - Use clones for each separate work. This is kind of difficult, take the
> > one-liner as example. Cloning a whole repo takes  ~5 minutes in our case
> > (lots of history). So people tend to quickly hack it in an already cloned
> > repository and run into the above situation.
>
> Are you saying that it takes 5 minutes to do a local clone? Or are you
> making a brand new clone over the network from your server. Sounds like the
> team hasn't yet internalized that all clones are equal, so you can keep a
> clean upstream local clone, pulling to which won't take very long, and
> cloning from locally shouldn't take very long either.

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

I suppose he could do something like this:
	
	# Need to do a one liner:
	hg clone local_project_wc quick_fix_wc
	cd quick_fix_wc
	# work work
	hg fetch ssh://authoritative_project
	hg push ssh://authoitative_project

That seems reasonable.

> > Also: I know that the centralized approach is not the most HG-ish way to
> > work with HG. But I also think that a lot of people are using it that
> > way, and it shouldn't be so difficult to do. One nice thing about HG is

It's almost a requirement for a corporate environment.  There often needs to 
be some authoritative interface between, say, product development and 
software release management.

--- SER


More information about the Mercurial mailing list