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