Strategies for push/merge problem?
Sean Russell
hg at ser1.net
Tue Jul 15 01:51:39 UTC 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