On Feb 9, 2012, at 10:37 PM, Jed Brown wrote:
> On Thu, Feb 9, 2012 at 22:19, Barry Smith <bsmith at mcs.anl.gov> wrote:
> dft Density Functional Theory solver for Ion Channels petsc-maint
> at mcs.anl.gov Thu, 28 Jul 2011 15:05:00 -0600 gz RSS Atom
> dft-fft unknown unknown Sat, 19 Dec 2009 13:49:50 -0600 RSS Atom
> dft-log Density Functional Theory solver for Ion Channels in Logarithmic
> Variables petsc-maint at mcs.anl.gov Tue, 14 Oct 2008 09:31:52 -0600 gz
> RSS Atom
> dft-mg Density Functional Theory solver for Ion Channels with Grid
> Sequencing petsc-maint at mcs.anl.gov Fri, 28 Nov 2008 13:15:07 -0600 gz
> RSS Atom
> dft-rfd Density Functional Theory solver for Ion Channels with Advanced
> Electrostatics petsc-maint at mcs.anl.gov Thu, 22 Dec 2011 13:56:52 -0600
>
> If you name it dft/log instead, then when you clone it, you get a directory
> called "log".
hg clone blahblah/dft/log mydft-log or dft/log if they keep a bunch
of them in the dft directory.
>
>
>
> Come on guys, it is completely moronic that bitbucket doesn't support
> subdirectories to hold repositories. No amount of rationalization can provide
> a reason for this absurdity.
>
> Some of Jed's rationalizations are going off the deep end.
>
> * In order to not have a Releases directory he states: "I think separate
> clones for every release is clutter."
>
> I think we should get rid of this thing called libraries? Who wants to share
> code anyway. We should just copy the source code of libc (and MPI, etc) into
> our packages. Since we won't be modifying the upstream source, it'll be easy
> to copy in a new version when they release one.
>
> Okay, I'm being silly now, but why do you want a sequence of separate clones,
> each of which is a strict subset of the last?
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
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).
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
Barry
