On Fri, Feb 10, 2012 at 9:23 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Feb 10, 2012, at 9:13 AM, Matthew Knepley wrote:<br>
<br>
> The thread has become too deep for me to read, hence the top posting.<br>
><br>
> Barry's question is the right one: What do we gain by changing?<br>
><br>
>   1) Reliability and Availability<br>
><br>
>    Barry, you should know that this crap about petsc.cs being backed up is farcical. We<br>
>    would have the same situation we had with the first 10 years of PETSc history again.<br>
>    BB is definitely more reliable in terms of backups, uptime, and connectivity (SSH issues).<br>
><br>
>    2) Better management support<br>
><br>
>    The infrastructure for supporting user permissions is better on BB. We don't edit a file,<br>
>     calling a script someone hacked together. We have accounts, and when accounts are<br>
>     shut down they go away. A user can manage his SSH key independently of us.<br>
><br>
> Those for me make it a slam dunk. However, I will ask the question in reverse: What do we<br>
> give up?<br>
<br>
</div>   I decent way of hierarchically organizing our repositories. Tell me how to do this on bitbucket and you have your slam dunk.</blockquote><div><br></div><div>Mailing BB.</div><div><br></div><div>   Matt</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> I think the only thing we give up is the security blanket of being able to log in<br>
> ourselves and mess with a machine directly.<br>
><br>
>     Matt<br>
><br>
> On Fri, Feb 10, 2012 at 8:26 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> On Feb 9, 2012, at 11:15 PM, Sean Farley wrote:<br>
><br>
> ><br>
> > 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.<br>

> ><br>
> > Why does the *server* have to have the subdirectory?<br>
><br>
>   Because I want to have a bunch of repositories organized in a hierarchical manner. You response seems to be:<br>
><br>
> 1)   no you don't want that   or<br>
><br>
> 2)  you should put them all in one giant repository   or<br>
><br>
> 3) have them in different bitbucket accounts (like a petsc account and a externalpackages account) that have nothing to do with each other.<br>
><br>
>   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.<br>
><br>
>   Barry<br>
><br>
><br>
><br>
><br>
> ><br>
> > $ hg clone bb://petsc/anothercoolthing subdirectory-that-can-suck-eggs/anothercoolthing<br>
> ><br>
> > 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 :-)).<br>

> ><br>
> > 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.<br>
><br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>