<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 12:09 AM, Sean Farley <span dir="ltr"><<a href="mailto:sean@mcs.anl.gov" target="_blank">sean@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":3c6">Two places in a file? The following<br>
<br>
[paths]<br>
barry = bb://BarryFSmith/petsc-dev<br>
<br>
adds 'barry/default' (and other branches) as a local tag(s).<br></div></blockquote><div><br></div><div style>I was looking at this</div><div style><br></div><div><a href="http://mercurial.selenic.com/wiki/RemoteBranchesExtension">http://mercurial.selenic.com/wiki/RemoteBranchesExtension</a><br>
</div><div><br></div><div><div>[paths]</div><div>default=<a href="http://hg.intevation.org/mercurial/crew">http://hg.intevation.org/mercurial/crew</a></div><div>crew=<a href="http://hg.intevation.org/mercurial/crew">http://hg.intevation.org/mercurial/crew</a></div>
<div>mpm=<a href="http://selenic.com/hg">http://selenic.com/hg</a></div><div><br></div><div>[remotebranches]</div><div>upstream=crew,mpm</div></div><div><br></div><div><br></div><div style>which looks like two places to me.</div>
<div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":3c6"><div class="im">
</div>Yes, that is why I forked remote-branches. So that I could remotely add<br>
bookmarks. But that's besides the point. You are muddying the waters<br>
here with talk of divergent bookmarks and Mercurial's internals. I'm<br>
trying to stick with the simpler model of pull-requests for now.<br></div></blockquote><div><br></div><div style>Pull requests are orthogonal to having multiple branches/bookmarks in a repository. I'm saying that the latter still appears to be painful with hg.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":3c6">
<div class="im"><br></div>To me, having 300 branches to look at is a crazy amount of information<br>
overload.</div></blockquote><div><br></div><div style>That's why keeps them in the remote namespace and does not show them to you unless you look for them. It is, however, much simpler than having 300 "remotebranches" coming from different repositories.</div>
<div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":3c6">
Granted, what I'm suggesting is for you and other devs that want to work<br>
on people's branches to manually add it. I can understand that's<br>
cumbersome for you but it is pretty straight-forward and easy to explain<br>
to new devs.<br></div></blockquote><div><br></div><div style>It's less scalable, more error-prone, and when debugging remotely, it's seems like we have to ask people to send the contents of their .hg/hgrc to figure out how they are set up. We can try it, but I think it will not work well.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":3c6">
I'll argue that most of what you're mentioning is useless without<br>
context; i.e. if I want to be hacking on someone else's branch then I<br>
have a reason to be looking at their work and discussing it with<br>
them.</div></blockquote><div><br></div><div style>This is a cumbersome way to get a summary of what's going on.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":3c6"><div class="im">
</div>How is having <a href="http://bitbucket.org/petsc/petsc-next" target="_blank">http://bitbucket.org/petsc/petsc-next</a> breaking this model?<br>
You'll have the remote forks of the devs you want to keep track of, then<br>
you can merge / bake things in petsc-next and edit the history when<br>
done.<br></div></blockquote><div><br></div><div style>How would I go about finding all feature branches that have been cooking in next for more than a week, but are not yet merged to master? If someone else merged it, I won't even be able to figure out from the history where the merge commit came from. Note that I _never_ merge 'next' into 'master', I only merge stable features.</div>
<div style><br></div><div style>If I'm rebuilding 'next' after a release, how do I make sure I have all the branches that did not graduate for the release?</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":3c6"><div class="im">
</div>You are doing a disservice here by sweeping under the rug the difficulty of<br>
switching an entire team to a new tool. Especially since what you are<br>
describing is achievable with mercurial: (a) create fork, (b) hack away,</div></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra" style>1. Note that this "recommendation" is still broken:</div>
<br><a href="https://bitbucket.org/petsc/petsc-dev/commits/featurebranches">https://bitbucket.org/petsc/petsc-dev/commits/featurebranches</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra" style>2. If we are going to change workflow significantly from the status quo, I think we should consider all the options. Sure, we may end up making only a small incremental change now, but if it's going to be a long progression, it may ultimately be better to do it all now.</div>
</div>