<br><br><div class="gmail_quote">On Mon, Jun 20, 2011 at 10:33 AM, Martin Geisler <span dir="ltr">&lt;<a href="mailto:mg@aragost.com">mg@aragost.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
&lt;snip&gt;<br><div class="im">
<br>
</div>I claim that you cannot collaborate (efficiently) on a versioned patch<br>
repository. I&#39;ve never seen it happen. It is hard enough to work<br>
together on files using patches -- working together on second-order<br>
patches makes things much harder.<br>
<br>
Personally, I&#39;ve worked on a set of versioned MQ patches with Henrik and<br>
I think it only worked because we took turns editing the patches.<br>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">&lt;snip&gt;<br>
I cannot be the only one who have looked at our development process and<br>
thought &quot;hey, wait a moment... they use *patches*? and they implicitly<br>
*rebase* them all the time? Why don&#39;t they use their own tool more?&quot;<br>
<br>
I know the answer is that email is incredibly flexible, but I also know<br>
that we&#39;ve talked about the problem of losing patches at the last two<br>
sprints. Bitbucket just launched a nice &#39;pull request&#39; feature that<br>
would let us get some overview back: people make a pull request on<br>
Bitbucket and we can reject/accept them there.<br></blockquote></div><br clear="all">FWIW, I really believe Martin is spot-on with these comments.  It&#39;s important to realize that in order to develop great product -- commercial or open-source -- one needs to understand his user base and dogfood his own product in the same way that his users use it in real-world situations.  This means using all of the features the team recommends to others as a solution for real-world problems.  It means using the tool on multiple platforms and purposely putting yourself in different use cases so you can see from an end-user&#39;s perspective what it is /really/ like to use the tool.<br>
<br>The development model the Mercurial project uses is simply not scalable to any kind of fast-moving, large development team with any kind of a sizable codebase and parallel feature development going on.  I would strongly encourage/support the movement towards a development model that is more current and realistic for large teams.<br>
<br>Cheers,<br>N.<br><br>-- <br><div><div><span style="color: rgb(153, 153, 153);"><b>Na&#39;Tosha Bard</b></span></div><div><font color="#999999">Build &amp; Infrastructure Developer | Unity Technologies</font></div><div>
<font color="#999999"><br></font></div><div><font color="#999999"><b>E-Mail:</b> <a href="mailto:natosha@unity3d.com" target="_blank">natosha@unity3d.com</a></font></div><div><font color="#999999"><b>Skype:</b> natosha.bard</font></div>
</div><br>