> > 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). > > > > hg clone -u release-3.2 https://bitbucket.org/petsc/petsc-release
hm - don't you miss all the patch commits from release date to the release tip? > 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. > > > Credential management is simpler because adding/removing keys and similar > can be done by the user instead of by emailing Satish. replaced by 'crate a bitbucket account - and email sean your bitbucket id' so eqivalent. Satish > 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. > > That said, I'm not deeply invested and would rather write code than argue > about where to store it.