[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

[Jed Brown]

On Wed, Mar 6, 2013 at 12:09 AM, Sean Farley <sean at mcs.anl.gov> wrote:

> 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 was looking at this

http://mercurial.selenic.com/wiki/RemoteBranchesExtension

[paths]
default=http://hg.intevation.org/mercurial/crew
crew=http://hg.intevation.org/mercurial/crew
mpm=http://selenic.com/hg

[remotebranches]
upstream=crew,mpm


which looks like two places to 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.
>

Pull requests are orthogonal to having multiple branches/bookmarks in a
repository. I'm saying that the latter still appears to be painful with hg.


>
> To me, having 300 branches to look at is a crazy amount of information
> overload.
>

That's why keeps them in the remote namespace and does not show them to you
unless you look for them. It is, however, much simpler than having 300
"remotebranches" coming from different repositories.


> 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.
>

It's less scalable, more error-prone, and when debugging remotely, it's
seems like we have to ask people to send the contents of their .hg/hgrc to
figure out how they are set up. We can try it, but I think it will not work
well.


> 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.
>

This is a cumbersome way to get a summary of what's going on.


> 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.
>

How would I go about finding all feature branches that have been cooking in
next for more than a week, but are not yet merged to master? If someone
else merged it, I won't even be able to figure out from the history where
the merge commit came from. Note that I _never_ merge 'next' into 'master',
I only merge stable features.

If I'm rebuilding 'next' after a release, how do I make sure I have all the
branches that did not graduate for the release?


> 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,
>

1. Note that this "recommendation" is still broken:

https://bitbucket.org/petsc/petsc-dev/commits/featurebranches

2. If we are going to change workflow significantly from the status quo, I
think we should consider all the options. Sure, we may end up making only a
small incremental change now, but if it's going to be a long progression,
it may ultimately be better to do it all now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130306/13ceae95/attachment.html>