On 28/03/2011 11:35, Nick Coghlan wrote:
On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore<p.f.mo...@gmail.com> wrote:
For people in the "clean history" school, I'd recommend looking at mq
for your personal use. But it's definitely an advanced feature of
Mercurial, so it may be better to understand core Mercurial (and at
least temporarily accept that Mercurial is based on the "keep all
history" school of thought, or you'll struggle to match the
assumptions of the documentation to your thinking :-)) before diving
into mq.
I'm seeing if I can get the best of both worlds by having a public
sandbox repo where I work on things (which has the full messy history
of development on its feature branches), and then just drop them into
the main repo as coherent patches. Once I land a patch, I'll close the
original feature branch in the sandbox, so merge conflicts won't be an
issue.
Mercurial makes merging easy enough that I'm happy with the way that
approach is working so far.
For any non-trivial work I think this is the best approach. You still
get all the advantages of working with mercurial (able to commit
frequently) without polluting the history of the core repository.
It has the major advantage of also being very simple to understand.
All the best,
Michael
Cheers,
Nick.
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
