[petsc-dev] Updating MOAB version during download

[Barry Smith]

On Jun 16, 2014, at 5:28 PM, Satish Balay <balay at mcs.anl.gov> wrote:

> On Mon, 16 Jun 2014, Barry Smith wrote:
> 
>> 
>> On Jun 16, 2014, at 4:31 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>>> Barry Smith <bsmith at mcs.anl.gov> 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
>> 
>> 
>> 
>> 
>> 
>>