Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] workspace management question
From: Eugene Loh (Eugene.Loh_at_[hidden])
Date: 2009-02-19 14:37:41

Terry Dontje wrote:

> Eugene Loh wrote:
>> Okay, thanks for all the feedback. New version is at:
>> If everyone is happy with that, I'll remove the old version, along
>> with the diagram.
> So I like the new text much better than the old, but I think your
> diagram is still pertinent in the context of the new text. The only
> issue I have with the diagram is you don't see the steps in the order
> that are given in the text but I am not sure that is possible to do.

I think the diagram contributes little to the new text and, in fact,
confuses things. The diagram really corresponds to the old description.

Jeff Squyres wrote:

> FWIW, I think your text is generally good enough (some nits below).
> You might want to say that "this is one way" or somesuch, because
> there are other variants (e.g., I typically commit multiple times
> before pushing, etc.). But I doubt it's worth going into that much
> detail.

Right. Let experts diverge from the notes as they will.

> Minor nits:

Speaking of which, I changed walla to voila. (You said elsewhere that
you didn't speak French.)

> - On the "put back to SVN" side, note that you might need to SVN add/
> remove as well (i.e., if you added or removed stuff in hg).

I'm confused. It would seem to me, you should do this after an "hg
update" in the combo workspace. What arguments should "svn add" take?
That is, how do you know which files were just added by "hg update"?

> It's also common to need to update various svn:ignore properties.

What does this mean?

> - On the "commit to my local hg" side, it's not always a good idea to
> just run a top-level "hg addremove" -- that may slurp in some kruft
> files that you have in your workspace. I usually use a finer-grained
> "hg add file1 file2 ..." approach (because I've been burned by the
> top- level "hg addremove" approach before).

Okay. Done.