February 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] petsc-dev on bitbucket
by Sean Farley 09 Feb '12

09 Feb '12

> > hg clone blahblah/dft/log mydft-log or dft/log if they keep a > bunch of them in the dft directory. > If you're using this as your argument, then why not the reverse? Why even look at the website *ever*? $ hg clone bitbucket/petsc/dft-log dft/log 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 > So, you're willing, right now, to patch 3.1? Or are you going to tell the person to update? Yeah, that's what I thought. > 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). > This won't change. Custom downloads can be provided. Why, look at what we have here: https://bitbucket.org/petsc/petsc-dev/downloads/old-people-suck.tar.gz > 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? $ 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.

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Barry Smith 09 Feb '12

09 Feb '12

On Feb 9, 2012, at 10:37 PM, Jed Brown wrote: > On Thu, Feb 9, 2012 at 22:19, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > dft Density Functional Theory solver for Ion Channels petsc-maint(a)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(a)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(a)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(a)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

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Barry Smith 09 Feb '12

09 Feb '12

On Feb 9, 2012, at 10:54 PM, Sean Farley wrote: > 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. > > What's completely moronic is that petsc.cs.itt is hosting so many repositories that are mostly cruft: > > Allen-Cahn-2D > Cahn-Hillard-1D > Cahn-Hillard-2D > FMM > FMM-dev > ams-dev > composing-nonlinear-solvers > cudaFMM > dft > dft-fft > dft-log > dft-mg > dft-rfd > externalpackages-old/MUMPS_4.7.3 > externalpackages-old/MUMPS_4.9.2 > externalpackages-old/ParMetis > externalpackages-old/ParMetis-3.1.1 > externalpackages-old/SuperLU_4.0 > externalpackages-old/SuperLU_DIST_2.2 > externalpackages-old/SuperLU_DIST_2.4 > externalpackages-old/UMFPACK-5.2 > externalpackages-old/f2cblaslapack > externalpackages-old/f2cblaslapack-3.1.1.q.old > externalpackages-old/fblaslapack > externalpackages-old/hypre-2.6.0b > externalpackages-old/sowing-1.1.11 > lwang-dev > multiphysics > petsc-dev-new??? > petscpathlib > pthread-paper > reacting_flow > releases/BuildSystem-2.3.1 > releases/BuildSystem-2.3.2 > releases/BuildSystem-2.3.3 > releases/BuildSystem-3.0.0 > releases/BuildSystem-3.1 > simpleConfigure > temp/petsc-dev-ts > > If you look at the repositories left, only tutorials and externalpackages exist. We can even put the latter here: > > https://bitbucket.org/externalpackages > This is fucking moronic. Its got no logical connection to petsc and your petsc-dev repository at all! I keep my papers in /usr/lib/papers, my talks in /usr/local/include/something and some of my source code in /someotherdisk/jed/src is that how you organize your files? Please point to where bitbucket explains why subdirectories are a bad idea. Barry > For the private paper repositories, bitbucket gives you an unlimited number of private repos for free. > > Some of Jed's rationalizations are going off the deep end. > > Woah! That's the pot calling the kettle black. > > * In order to not have a Releases directory he states: "I think separate clones for every release is clutter." > > You honestly think it's worth keeping repositories around that haven't been touched in 6 years? How is that not clutter? > > Face it, bitbucket has this really stupid feature. > > Funny, we say the same thing about your commit messages :-) > > I see no upside to bitbucket and hence I only see a downside, so why change? > > Do you not remember getting burned by fail2ban while at the Utah (Nevada?) workshop? > > Except Sean doesn't want to drag his ass over to IIT twice a year and people want to use buggy wireless networks. > > People! *None* of us would have to do *anything* to maintain the server. No more buying new hard drives, no more accidental shut-downs, *OTHER* people would fix that stuff. > > Tell me the real reason you want to use bitbucket. > > Just to upset you and then laugh when we see you pull your hair out.

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Sean Farley 09 Feb '12

09 Feb '12

> > 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. > What's completely moronic is that petsc.cs.itt is hosting so many repositories that are mostly cruft: Allen-Cahn-2D Cahn-Hillard-1D Cahn-Hillard-2D FMM FMM-dev ams-dev composing-nonlinear-solvers cudaFMM dft dft-fft dft-log dft-mg dft-rfd externalpackages-old/MUMPS_4.7.3 externalpackages-old/MUMPS_4.9.2 externalpackages-old/ParMetis externalpackages-old/ParMetis-3.1.1 externalpackages-old/SuperLU_4.0 externalpackages-old/SuperLU_DIST_2.2 externalpackages-old/SuperLU_DIST_2.4 externalpackages-old/UMFPACK-5.2 externalpackages-old/f2cblaslapack externalpackages-old/f2cblaslapack-3.1.1.q.old externalpackages-old/fblaslapack externalpackages-old/hypre-2.6.0b externalpackages-old/sowing-1.1.11 lwang-dev multiphysics petsc-dev-new??? petscpathlib pthread-paper reacting_flow releases/BuildSystem-2.3.1 releases/BuildSystem-2.3.2 releases/BuildSystem-2.3.3 releases/BuildSystem-3.0.0 releases/BuildSystem-3.1 simpleConfigure temp/petsc-dev-ts If you look at the repositories left, only tutorials and externalpackages exist. We can even put the latter here: https://bitbucket.org/externalpackages For the private paper repositories, bitbucket gives you an unlimited number of private repos for free. Some of Jed's rationalizations are going off the deep end. > Woah! That's the pot calling the kettle black. > * In order to not have a Releases directory he states: "I think separate > clones for every release is clutter." > You honestly think it's worth keeping repositories around that haven't been touched in 6 years? How is that not clutter? Face it, bitbucket has this really stupid feature. Funny, we say the same thing about your commit messages :-) I see no upside to bitbucket and hence I only see a downside, so why change? Do you not remember getting burned by fail2ban while at the Utah (Nevada?) workshop? > Except Sean doesn't want to drag his ass over to IIT twice a year and > people want to use buggy wireless networks. > People! *None* of us would have to do *anything* to maintain the server. No more buying new hard drives, no more accidental shut-downs, *OTHER* people would fix that stuff. Tell me the real reason you want to use bitbucket. Just to upset you and then laugh when we see you pull your hair out.

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Jed Brown 09 Feb '12

09 Feb '12

On Thu, Feb 9, 2012 at 22:19, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > dft Density Functional Theory solver for Ion Channels > petsc-maint(a)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(a)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(a)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(a)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". > > > 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 0

Re: [petsc-dev] petsc-dev on bitbucket
by Barry Smith 09 Feb '12

09 Feb '12

I know what we'll do. We'll imbed the directory name and the subdirectory name into the name of the repository: externalpackages_Chaco-2.2 tutorials_ACTS07 Wait a minute, someone who doesn't know about directories already did that: dft Density Functional Theory solver for Ion Channels petsc-maint(a)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(a)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(a)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(a)mcs.anl.gov Thu, 22 Dec 2011 13:56:52 -0600 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." * "Bitbucket's normal repository summary has space for this bit of text. It doesn't specifically have tags or automatic suggestions of repositories that might be related (but are not forks). I think the summary is good enough." Face it, bitbucket has this really stupid feature. I see no upside to bitbucket and hence I only see a downside, so why change? Except Sean doesn't want to drag his ass over to IIT twice a year and people want to use buggy wireless networks. Tell me the real reason you want to use bitbucket. Barry On Feb 9, 2012, at 9:03 PM, Satish Balay wrote: > On Thu, 9 Feb 2012, Jed Brown wrote: > >> On Wed, Feb 8, 2012 at 11:31, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >>> Yes. If you can't have that then it is a pretty crappy system. Sort of >>> like IBM 360 where you only had a root directory with a truckload of files >>> in it. In excusable in 2012 (or even 1972). >> >> >> Let's all stop using google and switch to 1998 Yahoo. It's so much easier >> to find things by navigating a hierarchy. > > all these comparisions don't make anysense to me. perhaps I'm dense. > > Whats the 'bitbucket' whay to easily get the info represented by this > single link: > > http://petsc.cs.iit.edu/petsc/ > > Here I can get 2 baisc type of info - the global info regarding all > the repos - and some grouping info - where I can identyfy the related > repo collections. > > Don't care if its implemented with hierirachal dirs or something else. > > Satish >

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Sean Farley 09 Feb '12

09 Feb '12

> > I think separate clone for release and dev is easy for people to work > with. I think separate clones for every release is clutter. > I agree and think that this would be ideal.

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Jed Brown 09 Feb '12

09 Feb '12

On Thu, Feb 9, 2012 at 21:54, Satish Balay <balay(a)mcs.anl.gov> wrote: > I interpreted sean as suggesting using 'hg tags' to organize relase patches > and dev changes in a single repo. > Release and dev in the same clone does not work (and was not suggested) unless bookmarks are used. Since that isn't familiar to a lot of Hg users, I'm not suggesting it. > And instead of using seprate clones > for releases as we do now - redo the work flow with 'hg tags' > > To me its not easy to implement branches with tags - hence the above > statement. [either you have named branches or you let the repo have > multiple heads - and keep tagging the release head and workarround the > confusion during merges etc. I'd rather deal with these issues in > separate clones for release/dev] > I think separate clone for release and dev is easy for people to work with. I think separate clones for every release is clutter.

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Satish Balay 09 Feb '12

09 Feb '12

On Thu, 9 Feb 2012, Matthew Knepley wrote: > On Thu, Feb 9, 2012 at 8:59 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > On Thu, 9 Feb 2012, Sean Farley wrote: > > > > > > > > > > Hg named branches are kind of screwy and bookmarks (which are less > > screwy) > > > > are still an "extension" > > > > > > > > > > This is true. Named branches are directly inherited from older versioning > > > systems (cvs, svn, etc.). After 2.0 Matt Mackall was convinced that > > > bookmarks so be completely analgous to git's branching: > > > > > > $ hg branch foo > > > marked working directory as branch foo > > > (branches are permanent and global, did you want a bookmark?) > > > > > > Mercurial 2.1 includes fixes that move and update bookmarks automatically > > > (and also allow pulling divergent bookmarks: foo@1, foo@2) > > > > > > so it makes sense to have separate clones to use for release management. > > > > But these releases get merged back, so just tagging them would place > > the > > > > tarball in the right place. > > > > > > > > > > Righto. > > > > > > > > > > But PETSc release tarballs include generated documentation, so using > > > > bitbucket's auto-generated tag-tarballs is not enough for releases. > > > > > > > > > > Ah, that's right. I think this could be fixed by using the tag info in > > the > > > scripts that generate the documentation. > > > > Sure alternatives are possible. I guess the primary question is: is > > are you suggesting this alternate workflow - just becuase its possible > > - or because its better? This conversation started off with solving a > > different problem - and then turned into changing workflow. > > > > We have a decent workflow currently - and the whole change of workflow > > [eventhough its possible] -I don't think buying us much. And I suspect > > it has additional complexity which some of us don't want to deal with. > > > > I do not understand how this changes workflow. It does not change mine at > all. > My workflow relies on being able to push and pull from repositories. We can > still do this. We do gain reliability, and backups. > > Please explain what we cannot do now. this part of the conversation is more about changing workflow wrt throwing away 'release clones' and maintain all release patches in a single clone [initially a single dev clone - and later modified to a single release and single dev clone] satish

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Satish Balay 09 Feb '12

09 Feb '12

On Thu, 9 Feb 2012, Matthew Knepley wrote: > On Thu, Feb 9, 2012 at 8:26 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > On Wed, 8 Feb 2012, Sean Farley wrote: > > > > > > > > > > Hell, if you *really* want to, just create the account: > > petsc-release(s) > > > > then the URL would be > > > > > > > > http://bitbucket.org/petsc-release/petsc-3.1 > > > > > > > > > > Actually, it's even easier than that: > > > > > > https://bitbucket.org/petsc/petsc-dev/downloads > > > > > > which provides downloads for all taged changesets. > > > > tags are no good. we implrement branches in different clones. > > > > I am not sure what you mean by this. Let me be explicit. > > This organization is semantic, and Completely outside the version control > structure. I want something to tell me "this repo is about simulating > rockets" > like Kit, the voice in Michael's car. Tags are fine for this. So is a > hierarchy. > So is silly XML metadata. I interpreted sean as suggesting using 'hg tags' to organize relase patches and dev changes in a single repo. And instead of using seprate clones for releases as we do now - redo the work flow with 'hg tags' To me its not easy to implement branches with tags - hence the above statement. [either you have named branches or you let the repo have multiple heads - and keep tagging the release head and workarround the confusion during merges etc. I'd rather deal with these issues in separate clones for release/dev] satish

1 0