On Fri, Feb 10, 2012 at 9:23 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > On Feb 10, 2012, at 9:13 AM, Matthew Knepley wrote: > > > The thread has become too deep for me to read, hence the top posting. > > > > Barry's question is the right one: What do we gain by changing? > > > > 1) Reliability and Availability > > > > Barry, you should know that this crap about petsc.cs being backed up > is farcical. We > > would have the same situation we had with the first 10 years of PETSc > history again. > > BB is definitely more reliable in terms of backups, uptime, and > connectivity (SSH issues). > > > > 2) Better management support > > > > The infrastructure for supporting user permissions is better on BB. > We don't edit a file, > > calling a script someone hacked together. We have accounts, and when > accounts are > > shut down they go away. A user can manage his SSH key independently > of us. > > > > Those for me make it a slam dunk. However, I will ask the question in > reverse: What do we > > give up? > > I decent way of hierarchically organizing our repositories. Tell me how > to do this on bitbucket and you have your slam dunk. Mailing BB. Matt > > Barry > > > > I think the only thing we give up is the security blanket of being able > to log in > > ourselves and mess with a machine directly. > > > > Matt > > > > On Fri, Feb 10, 2012 at 8:26 AM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > > > On Feb 9, 2012, at 11:15 PM, Sean Farley wrote: > > > > > > > > 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. > > > > > > Why does the *server* have to have the subdirectory? > > > > Because I want to have a bunch of repositories organized in a > hierarchical manner. You response seems to be: > > > > 1) no you don't want that or > > > > 2) you should put them all in one giant repository or > > > > 3) have them in different bitbucket accounts (like a petsc account and a > externalpackages account) that have nothing to do with each other. > > > > Just admit that not supporting a directory structure at bitbucket is > lame and stop coming up with lame reasons why it is ok. Then get bitbucket > to add this elementary support and we'll be all set. > > > > Barry > > > > > > > > > > > > > > $ hg clone bb://petsc/anothercoolthing > subdirectory-that-can-suck-eggs/anothercoolthing > > > > > > 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 :-)). > > > > > > I'll let Jed explain about forks and have the reverse look-up (how > many people have forked petsc). For me, it's drop-dead simple management. > > > > > > > > > > -- > > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > > -- Norbert Wiener > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120210/f79f6e46/attachment.html>