[petsc-dev] subrepositories

[Satish Balay]

A few comments about the model and expectations [valid or invalid]

[a] 

Barry's concers [latest buildsystem with latest petsc-dev] assumes no
incompatible changes [to BuildSystem are pushed]. This assumtion is
correct only if buildsystem chages are always done in sync with
petsc-dev and always tested with petsc-dev - before pushed.

In this case a single repo is the correct model.

However Matt likes to keep BuildSystem separate to support potentially
other projects. 2 cases here:

[b]

someone else [not using petsc] is making change to buildsystem and
testing & commiting to BuildSystem. In this case - such changes can
break petsc-dev - [so always latest changes as Barry would want- is
the wrong thing here].  Here subrepo model [where Matt has a different
master for BuildSystem and petsc-dev has its own subrep of buildsystem
- and they get synced frequently] is appropriate.

[c]

 Matt is the only person making fixes for the 'other projects' i.e all
changes do get tested in petsc-dev context. In this again a single
repo is the correct thing. The 'other project' users who need
buildsystem [without petsc-dev] could get it with perhaps some
auto-generated buildsystem-other repo - with perhaps some triggers
[that does equivalent of 'bk csetprune' perhaps with hg convert']

Currently we are using [b] as the reason for split repo - but using
the workflow from [c] - giving rise to expectations of [a]

Satish

On Thu, 24 Mar 2011, Barry Smith wrote:

>  My concern is simple.  (1) Someone adds some fixes to BuildSystem,
>  commits and pushes.  (2) Someones uses PETSc with the BuildSystem
>  subrepository does a pull in PETSc and NEVER gets the stuff that
>  was put into BuildSystem. Given this I don't care how great it is
>  that you can get consistent rollbacks and all kinds of good stuff
>  by having a subrepository, nor do I care how hard it would be to
>  get my model to work; this one flaw ruins all the great stuff you
>  do get.

> On Mar 24, 2011, at 5:11 PM, Jed Brown wrote:

> > To really have a single repository view without "redundant"
> > commits to both BuildSystem and PETSc, and with some useful
> > rollback semantics, you would have to really make one
> > repository. As I understand it, Matt is rather opposed to directly
> > importing BuildSystem into PETSc. I don't know how many people use
> > BuildSystem without PETSc, there is certainly no
> > backward-compatibility so it would be awfully hard to recommend.