[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

[Sean Farley]

Jed Brown writes:

> On Tue, Mar 5, 2013 at 10:19 PM, Sean Farley <sean at mcs.anl.gov> wrote:
>
>> > 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.
>>
>
> It's two places in a file, compared to 'git remote add my-remote-name
> the.url:repo'.

Two places in a file? The following

[paths]
barry = bb://BarryFSmith/petsc-dev

adds 'barry/default' (and other branches) as a local tag(s).

I could implement 'hg pull bb://seanfarley/petsc-experiment --add
foo' (I made up those options just now; haven't decided how to present
them to the user yet) to save a command, if you really want, but that's
on the back-burner for now.

> The remote bookmarks are still not namespaced so I still can't safely fetch
> from all remotes before going offline (and even if I'm online, many
> operations are relatively slow). After 'hg pull somewhere' (rather than
> pulling a specific branch/bookmark), I don't have a way to keep track of
> which bookmarks came from where. At least divergent conflicts give warnings
> "divergent bookmark yyy stored as yyy at default", but other bookmarks are
> automatically fast-forwarded and new bookmarks are added (I can't find an
> option to treat everything as a "divergent" bookmark even when it could
> fast-forward. I'd much prefer that.)
>
> This is much "too global" management of bookmarks if you ask me.

Yes, that is why I forked remote-branches. So that I could remotely add
bookmarks. But that's besides the point. You are muddying the waters
here with talk of divergent bookmarks and Mercurial's internals. I'm
trying to stick with the simpler model of pull-requests for now.

>> 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.
>>
>
> With a git repository, those branches really do not affect the user. Try
> this

[snip]

> So I can easily browse ongoing projects ('git log gitster/ap/log-mailmap')
> and I can work on them ('git checkout ap/log-mailmap', hack away...) but
> unless I'm directly interacting with a branch, I'm totally unaffected by
> those ongoing projects and never see them in my normal workflow ('git log',
> 'git branch', etc).

To me, having 300 branches to look at is a crazy amount of information
overload. Plus, it's a huge change in workflow. Hence, I am trying to
nudge people incrementally into the pull-request model. It won't shatter
people's current workflow (even those that use mercurial as a
local-subversion-type of repo). Not breaking people's current workflow
(no matter how much you dislike it) seems like a huge win to me.

Granted, what I'm suggesting is for you and other devs that want to work
on people's branches to manually add it. I can understand that's
cumbersome for you but it is pretty straight-forward and easy to explain
to new devs.

I'll argue that most of what you're mentioning is useless without
context; i.e. if I want to be hacking on someone else's branch then I
have a reason to be looking at their work and discussing it with
them. Or if I'm assigned to review their patches, then I have to pull
them from somewhere. That's either their own fork or some bookmark or
some email thread.

> If we are going to consider allowing topic branches to "cook in next" for a
> while (to get tested in interaction with the rest of the system) before
> being merged to a stable branch, then we need to keep these bookmarks
> around somehow, yet it's unacceptable for them to intrude on normal
> workflow. I still haven't heard of a viable plan in Hg's roadmap.

How is having http://bitbucket.org/petsc/petsc-next breaking this model?
You'll have the remote forks of the devs you want to keep track of, then
you can merge / bake things in petsc-next and edit the history when
done.

You can nitpick about this workflow, but I think it achieves quite a
bit; and as a bonus it's an opt-in model (i.e. only you and the devs
that want this workflow have to change; others can keep chugging along).

>> 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.
>
>
> In all cases, the contributor workflow is (a) create topic branch, (b) hack
> away, (c) push to personal repo and submit pull request OR (c') email patch
> series to list. The distinction in all these possibilities is how we as
> maintainers manage review, testing, and release of those contributions.

You are doing a disservice here by sweeping under the rug the difficulty of
switching an entire team to a new tool. Especially since what you are
describing is achievable with mercurial: (a) create fork, (b) hack away,
(c) push to personal repo and submit pull request OR (c') email patch
series to list.