<div class="gmail_quote">On Thu, Feb 9, 2012 at 23:01, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":8">1) They are not actually subsets since eventually patches in a release cannot be applied to the dev so the next release does not have everything that went into a previous release<br></div></blockquote><div><br>
</div><div>If you merge back to petsc-dev right away after committing to the latest release (bug fix/backported feature), then every patch is always in petsc-dev. We don't always do this right away because it's an extra step and makes for more merge commits (cosmetic). Looking at the entire history, we never apply patches to old releases anyway, only the current one. Since we always eventually merge back, those old patches are a real part of each later release.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":8">
2)   Because any idiot who simply wants petsc-3.0.0 (because they are using Joe's code which they are not allowed to update) can simply see the list of files and grab the one they want. They need to know nothing about nothing to do this. Not everyone in the world is an expert Mecurial user or even a crappy Mecurial user (just look at me).<br>
</div></blockquote><div><br></div><div>hg clone -u release-3.2 <a href="https://bitbucket.org/petsc/petsc-release">https://bitbucket.org/petsc/petsc-release</a></div><div><br></div><div>then "hg tags" shows them what else is available. Hg tags, bookmarks, and branches integrate with guis so users can use the tools they might be useful to navigate releases instead of only choosing from a list on the website. I don't know how much this matters, but I think simple directions are enough for moving around.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":8">
<br>
Even if you were right about this specific issue (which you are not) it doesn't matter. All you've done is removed the need for a releases subdirectory. What about tutorials subdirectory, externalpackages subdirectory, anothercoolthingwethinkofnextweek subdirectory.<br>

<br>
 Please explain to me the real reasons bitbucket is better than petsc.cs.  and stop rationalizing around bitbuckets weaknesses. Every choice has some tradeoffs and I haven't heard much about bitbuckets advantages so I am confused why you guys are so in love with it. (Well I understand Sean's reasons, being pretty lazy myself :-)).<br>

<br>
  So far:<br>
    pros -- support HTTPS               ----------  yes that is an advantage<br>
                backed up                        - ----------  hg repositories are always backed up (as is petsc.cs.... anyways)<br>
                 less likely to go down  ------------- some advantage,  but its been averaging just twice a year and it is trivial to switch to another system temporarily as Sean demonstrated.<br>
                 is far cooler than a lamo university machine</div></blockquote></div><br><div>Credential management is simpler because adding/removing keys and similar can be done by the user instead of by emailing Satish.</div>
<div><br></div><div>I'm not deeply invested either way, but I'm not seeing a compelling argument not to use it. Many of the things you are requesting (separate clones for each release, directory hierarchies to get to the repository) would be considered "quirks" by other projects. I don't think PETSc is that "special" that it needs to use different repository management.</div>
<div><br></div><div>That said, I'm not deeply invested and would rather write code than argue about where to store it.</div>