[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

[Sean Farley]

Jed Brown writes:

> On Tue, Mar 5, 2013 at 9:05 PM, Sean Farley <sean at mcs.anl.gov> wrote:
>
>> >> And this is why I think git makes things more complicated than need
>> >> be.
>> >>
>> >
>> > By keeping remotes namespaced and having exactly one branching
>> > mechanism?
>>
>> By not forcing any branching? All of what you have described so far can
>> be accomplished, easily, with forking / pull-requests and the
>> remote-branches extension today [1].
>
>
> This does not appear to namespace the branches and it looks like you have
> to edit .hg/hgrc for each remote that you want to track. It is quite
> different from namespaced branches/bookmarks.

Sure, but only the person wanting to pull has to add a path to their
.hgrc which is extremely easy to understand and do.

> I guess that's what you plan
> to work on implementing.

I guess. It's just as easy to make an alias do this so the motivation is
pretty low.

>> You can get even more fancy
>> after Atlassian implements non-publishing repos.
>>
>> >>  > 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.
>> >>
>> >
>> > To start with, 'hg log' shows you all bookmarks. The normal user
>> following
>> > petsc-dev will issue
>> >
>> > $ hg pull -u
>> > $ hg log
>> >
>> > to see what is new. The fact that many normal commands show all the
>> > bookmarks makes them disruptive. The ability to customize those commands
>> or
>> > modify them to restrict to the current bookmark is besides the point
>> > because the default is overwhelming.
>>
>> See my above recommendation. You don't need bookmarks or anything else
>> fancy. Just remote-branches, really.
>>
>
> Sounds like this has come back to the old argument that branches/bookmarks
> aren't a useful feature and that separate clones should be used for
> everything.
>
> Barry pushing to his own fork was fine for this case, but I don't buy the
> argument that clones are a viable replacement for branches. Even Mercurial
> concluded as much by hg-1.6 when they added pushing and pulling bookmarks.

You misunderstand me. I think branches/bookmarks are pretty cool and
useful. I also think using changeset evolution (to achieve the shared
garbage-collection of git's unrefed heads) is cool, too. But those workflows
are advanced and require each user of the repo to conform, without
buying all *that* much more than the fork / pull-request model.

Instead, what I am suggesting is taking incremental steps in that
direction. The fork / pull-request model is pretty darn simple and
allows each developer to work with either workflow (or even some
hybrid). If Barry doesn't want to ever change his habits, then it's
fine. Others could pull, clean-up, and merge his work.

On top of that, new developers (including people more comfortable with
subversion / cvs / centralized development) won't be bombarded with too
much and can work in their own fork as they please.