[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

[Sean Farley]

Jed Brown writes:

> On Tue, Mar 5, 2013 at 7:48 PM, Sean Farley <sean at mcs.anl.gov> wrote:
>
>> Huh? gitifyhg should only be pulling the new changesets (isn't it
>> keeping some kind of hash mapping around?).
>>
>
> Gitifyhg keeps a separate hg clone per remote because we could not find a
> reliable way to keep branches and bookmarks distinct. I would much prefer
> it to use one hg repo that can pull quickly from any new place, but we
> would need to be able to _guarantee_ that there were never collisions and
> that no operations moved existing bookmarks. Maybe the extension you
> mentioned will be able to support this at some point? Will it be able to
> update named branches for different remotes without a race? (I don't know
> if you can commit on one named branch (in a namespace) while writing the
> unnamespaced branch name into the commit.)

And this is why I think git makes things more complicated than need
be. Also, cantankerous but I digress.

>> Namespacing is completely
>> unrelated to this, and IMO, unnecessary. For something as easy as this
>> clean-up, all you need is one bookmark.
>>
>
> As I mentioned before, bookmarks in hg are much more in-your-face than git
> branches. Up until now, we have not allowed multiple heads in any PETSc
> repositories. Can we do it without confusing people?

I disagree about them being in your face. I think you're making this
workflow more complicated than need be.

As for having multiple heads, I wouldn't recommend that workflow for
this group just yet. The main drawback is Bitbucket not allowing
non-publishing repos in case anyone screws something up (which will
happen).

Just use the pull-request model for now. This will already allow a more
flexible workflow and will do it in an incremental step (as opposed to
forcing advanced concepts and 'gotchas' on *everyone*).