[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

Jed Brown jedbrown at mcs.anl.gov
Tue Mar 5 19:56:35 CST 2013


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


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


> If you want to get fancy, then
> you could clean-up history and whatnot but as I mentioned before,
> Bitbucket doesn't allow it. You could, of course, host your own server
> (ala Rhodecode) or, you know, quit your bitching and shoehorning
> unneeded concepts (namespaces, in this case).
>
> Your comment about a perpetually unstable Python API is a strawman. You
> must be using private functions and not the command server / API.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130305/9645554c/attachment.html>


More information about the petsc-dev mailing list