On Jun 16, 2014, at 5:28 PM, Satish Balay <[email protected]> wrote:
> On Mon, 16 Jun 2014, Barry Smith wrote: > >> >> On Jun 16, 2014, at 4:31 PM, Jed Brown <[email protected]> wrote: >> >>> Barry Smith <[email protected]> writes: >>>> Jed has pointed out that a “branch” is not enough information, so >>>> what should we use in the xxx.py so that the correct thing is built >>>> when I build PETSc with a particular branch??? >>> >>> The commit hash, which is exactly what we have now. >> >> 1) It is a manual beasty that someone has to edit moab.py and change on a >> regular basis? This doesn’t work as proved by the current fiasco. >> > > I disagree. The problem stated previously was wrong - 'petsc-dev should track > latest moab-dev' > > If we stepback and state the workflow problem - and agree on the workflow - > updating hash > is part of the workflow could be done. > > If automatic tracking is critical - then we should look at 'git submodule' > > >> 2) It does not give me access to the branch so that I can make changes. Say >> I am working on feature-dmmoab in PETSc and see a little bug in the moab >> branch that (indirectly only since I am at some stupid headless commit-hash >> instead on a branch) I am pointing to, that if I quickly fix I can push and >> make life easier for my entire team of eight developers. I need to manual >> figure out what branch corresponds to the commit-hash thing I had checked >> out, change to that branch in moab, fix the branch in moab, push it and then >> comeback and edit moab.py in PETSc to point to the new commit-hash beasty of >> the moab branch. > > We don't that luxuary of finding a bug in petsc [from nightly builds] > and quickly fixing it in the appropriate branch anyway. We have to run > a couple of git commands to do the appropriate thing. I would expect a > smilar thing with moab would be fine. [its just that its more of a > black-box to us petsc users wrt branch org]. But I don't see why > --downlaod-package should be burdened with keeping track of 'git > branches' which git doesn't track anyway. Because I sure as hell am not going to do something manually that can be done automatically. The reason I added —download-xxxx was NOT actually for end users (though they benefit from it greatly) BUT because __I__ refuse to keep downloading and installing over and over again over the years the same damn package as it evolves. I haven’t installed hypre in 10+ years (15?) manually, yet at least once a month I use —download-hypre image the wasted time if I still did it manually. Barry > > Satish > >> >> This is why I keep circling back to “branch” instead of commit hash in >> the moab.py; >> >> So somehow I would like the moab.py to “know” about the associated moab >> branch (if there is one) as well as a commit-hash. Now when I checkout the >> PETSc feature-dmmoab I want the branch checked out (at a particular >> commit-hash? Is that possible?) Now if I update the moab branch with a new >> commit then when I commit my feature-dmmoab I want it to automatically >> update the “commit-hash” in the moab.py >> >> Manually expecting people to switch from a commit-hash to its >> corresponding branch in the moab repository and to ALWAYS put the right >> thingy in the moab.py is totally fucking unrealistic. It is not a practical >> workflow. >> >> You might think this is all academic nonsense and not to worry about it >> but say I am doing a project that involves 3 repositories PETSc, moab, and >> saws and have a branch in each that coordinates with a branch in each of the >> others (and I am changing code in all three of them) and I am doing this >> with a team of five people. Expecting all five people to always do the right >> thing in coordination without automated help is impossible. So where does >> the help come from, some git feature, some other tool???? >> >> Barry >> >> >> >> >> >>
