[petsc-dev] petsc-dev on bitbucket

[Barry Smith]

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