Pulling and working on Mercurial repository with multiple developers

Question

Please bear with me....

(Edit...)

╔════════════╦═══════════════════╦══════╗
║ repo name  ║       role        ║ user ║
╠════════════╬═══════════════════╬══════╣
║ RepoMain   ║ production        ║ Mr.A ║
║ RepoTest   ║ test server       ║ QA   ║
║ RepoB_vm   ║ Mr.B's vm         ║ Mr.B ║
║ RepoB_home ║ Mr.B's final repo ║ Mr.B ║
║ RepoC_vm   ║ Mr.C's vm         ║ Mr.C ║
║ RepoC_home ║ Mr.C's final repo ║ Mr.C ║
╚════════════╩═══════════════════╩══════╝

You can imagine Mr.A works with other people so he has his own repository (same project)

There are several hot newbiew questions that I think I am still not over with.

basic workflow working on your own VM (virtual machine)

Commit your changes --> pull from test server to Repo_vm --> run your test on vm --> success then ask QA to pull from Repo_home

Is this the best workflow possible? I am always afraid of merge problem (sometimes newer changes went missing.. I had that one terrible experience). I don't think there is any big deal with production <--- test server as it's one-way. That sounds like a safe merge.

But multiple developers using the same test server repo, if we do this we will end up with Michael Myers chasing us down.

To expand the above workflow more explicitly...

1. commit changes on vm
2. pull from test server
3. run tests on vm
4. if all passes, update home repo
5. ask QA to pull from repo_home

---

With pull request in mind, is this a better workflow?

1. commit changes on your own VM
2. pull changes from test server for the latest alpha version
3. run tests locally
4. if all goes well, push to your home repo on your own account
5. submit a pull request
6. if you are at the front of the queue, make a clone version on the test server (sandbox envrionment) and then do the merging (test server might have the latest that is different from the last alpha version committed in home repo)
7. if test passes, he then tell QA to pull from merged sandbox repo
8. run tests
9. push to production on scheulde

Q2: What do you mean by QA giving limited time?

Q3: How often should developers pull from test server (contains the latest alpha stable version)?

Thanks.

Answer 1

Merging is a tricky problem. Mercurial does a pretty good job of handling things automatically, but it can't solve conflicts. That is best left to a person, and the best people for doing that are the developers making the changes. Don't make the QA merge anything. Merging conflicts requires careful attention to detail and should not be taken lightly. Careless merging is a problem no software can solve.

I think your workflow is fine. QA should treat pull requests like a queue. When a developer gets to the front of the queue, he's given an opportunity to pull, merge, and test. Once he's finished, he notifies QA, who then pull his changes. Since no other code has entered the repository, QA is guaranteed not to have to merge.

QA could also give developer's a limited amount of time to merge, build, and test, depending on the speed of your processes and the size of a developer's changes. That way, you don't get a huge queue of changes piling up behind the poor developer struggling to get things working.