[petsc-dev] petsc-dev on bitbucket

[Jed Brown]

On Thu, Feb 9, 2012 at 23:01, Barry Smith <bsmith at mcs.anl.gov> wrote:

> 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
>

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.


> 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

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.


>
> 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.
>
>  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 :-)).
>
>  So far:
>    pros -- support HTTPS               ----------  yes that is an advantage
>                backed up                        - ----------  hg
> repositories are always backed up (as is petsc.cs.... anyways)
>                 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.
>                 is far cooler than a lamo university machine
>

Credential management is simpler because adding/removing keys and similar
can be done by the user instead of by emailing 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120209/75ccfee8/attachment.html>