Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] workspace management question
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-02-19 10:37:46

On Feb 19, 2009, at 10:16 AM, Eugene Loh wrote:

> But, I'd like to understand this better. Jeff's e-mail above has an
> "hg up" before the "svn up". But, I was trying to organize the
> steps in terms of stuff that propagates "from left to right" (from
> OMPI central repository out to HG clones) and stuff that propagates
> "from right to left" (from HG clones back to central repository).
> Changes could be happening anywhere along the way (people putting
> code back to central repository or combo workspaces while you're
> doing development work in a clone), and so changes have to be
> propagated in both directions. Merges could happen at different
> points.
> Anyhow, I had an "hg up", but it's sitting on the right-to-left
> trail. It's step #2 on the return trail. It's at the bottom middle
> of the diagram. Isn't this sufficient? Doesn't "svn up" bring
> updates from the central repository to the combo workspace, while
> "hg up" brings the changes from the clones into the combo? So, in
> the "left/right" organization, they belong to different directions.

Yes... and no. :-)

I do the "hg up" in both cases (r2l and l2r) because

a) I may have forgotten to do it in one case (e.g., "hg push" doesn't
automatically "hg up" at the target; I rarely login to the target
machine to run "hg up" after an "hg push")
b) others may have done an "hg push" to my repo without a
corresponding "hg up" (i.e., even if *I* am religious about running
"hg up" after "hg push", others may not be)
c) it can create confusion/fear/mayhem/conflicts/complicated merges if
there is stuff in the hg repo but not in the working directory before
doing the "svn up"

But you're correct that if you *always* "hg up" after "hg push", then
the "hg up" before the "svn up" should be unnecessary. My experience
has been that it safer to assume that that is not true in practice.

Jeff Squyres
Cisco Systems