On Mon, 16 Jun 2014, Satish Balay wrote: > On Mon, 16 Jun 2014, Barry Smith wrote: > > > When Vijay, or some one else doing something else says; hey Barry please > > take a look at my branch xyz and build it and test and add features a, b, > > c, ALL THEY SHOULD NEED TO TELL ME IS branch xyz, I check it out and start > > building. If they need to tell me also get branch wyx of moab and branch > > abc of XYZ then we are NOT using tools efficiently (let’s just email the > > files back and forth). Each branch should have all the information needed > > to build for that branch, this simply means each branch has IN the > > appropriate xxxx.py package file the correct information about what other > > packages versions to use. This is actually easy except for > > Note: If I read this correctly you are not editing/fixing commiting to > moab repo. > > To me it looks like you are 'mercurial subrepo' workflow. Perhaps an > equivalent thing exists for git. Jed might chime in. > > And yes you can get equivalent thing with 'xxxx.py:gitcommit=xyz' - if > this is set correctly [not the gitcommit=branch/head thingy]. I think > this is what Jed was also advocating..
I should modify this statement. With hg-subrepo - one would do: hg update [commitid] to get a consistant snapshot of petsc+moab With 'xxxx.py:gitcommit=xyz' one would do: git checkout [commit-id] rm -rf arch* ./configure --download-moab=1 to get equivelent functionality [resulting in a git clone each time. This will presumably be fixedup in the future] Satish > > > merging to next and master where you may not want to drag along exactly > > the repository branch info that was used with the branch. (this relates to > > Vijay’s question). > > Dragging gitcommit=xyz to master is not a problem [draging gitcommit=head is > a problem] > > > The tools manage the coordination, people don’t mange coordination with > > notes on scraps of paper and rumors in the hallway about what commit of > > moab they should use with what branch of petsc. > > I agree one should use tools to simplify as much as possible. But configure > should > not be the only tool that bears this burden. [to me workflow is partly a > social > contract between team members to co-ordinate in a predetermined way]. > > > > > 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??? > > commit-id, tag. > > Branch is also a 'tag' but its a moving tag - [with non-reproduceable > state]. I think this is Jed's objection. [and mine as well [wrt > gitcommit=master-head] > > Satish >
