More SVN->HG questions

[Jeff Squyres]

Many thanks for all the replies to my first question.  We'll take this  
all back and talk amongst ourselves about it.

Does anyone have any advice on the 2nd question, perchance?

> 2. With a distributed system like Mercurial, we're anticipating that a
> bunch of our developers will have private / internal repositories
> where they do their main development, potentially pulling down from
> the central trunk/default HG repo over time, etc.  And then pushing
> back up to trunk/default when they're ready.
>
> Indeed, several of us are using workflows like this, but the final
> "push" upstream is an SVN commit -- so all the HG history is lost.
> This actually works out fairly well, because we don't want all the
> intermediate commits, merges, etc. to go upstream.  Specifically, we
> find that we have lots of "throwaway" commits in our internal
> repositories -- committing just to backup, or to push to a different
> (internal) system to test, etc.  Hence, we have lots more commits than
> are really necessary to go back to the official trunk/default HG
> repository.  Not only will all these extra commits "pollute" the
> common repository that we all share, it will also make moving commits
> to release repositories much more difficult (because instead of moving
> 1 commit, you have to move N commits, and they may be deeply
> intertwined in history).
>
> How to other projects typically handle this kind of scenario?  Do your
> developers use the rebase extension, or mq?  Or do you do something
> else?
>
> Any workflow advice that other multi-person projects have would be
> helpful.
>
> Thanks for your time!


-- 
Jeff Squyres
Cisco Systems