4

We are going to be building a new project using Mercurial as our version control system.

I'm still trying to fully understand what my workflow should look like, so I've listed below a case that I need some help undertanding.

A single application with multiple modules (Each module being hosted in its own repository) Multiple developers need to make changes to the same module. How should this be managed?

  • Should a hg pull be done and all changes be made on the local developers machine. Once those changes have been made the changes are pushed to dev.
  • Should each feature/bug fix get a new repository or branch on the server and the developer pushes his changes from his local hg to the remote hg. Once the feature is completed that repo/branch is merged back into dev.
  • Or a combinatiom of both. Small changes go straight into dev, and a feature that could take some time gets its own branch/repo.
  • Or any other strategies that you think are better suited.
Improve this question

4 Answers 4

Reset to default
2

You really don't need to make a separate repo/branch for every single changeset, since the concept of a changeset is kind of doing that for you.

I use branches for major features, and the main purpose a branch serves for me is being able to quickly and easily do "hg up branchname" or "hg up default" to switch between working on my new feature and working on bug fixes in the current codebase.

"Or a combinatiom of both. Small changes go straight into dev, and a feature that could take some time gets its own branch/repo."

This is a perfectly suitable option.

Don't forget that you can also "hg serve" to share changesets between devs.

Improve this answer
2

Suggestion: Why would each module be in a separate repo? Are they just that sufficient independent that an entirely separate repo is necessary?

With your scenario of multiple people working on the same module you just need to follow the general DVCS methodology: Work, make possibly many commits, at the end of the day pull any changes from dev and merge them, and lastly push to dev.

Improve this answer
1
  • It's just the way that I am leaning towards organizing the code base, however I haven't yet decided between the repo per module or application per repo
    – Tim Sparg
    Jun 2, 2011 at 23:42
1

First off, are the modules project independant?, if not, consider avoiding using subrepos. Subrepos are considered a feature of last resort.

Secondly, don't go wild with the clones. Some use it instead of creating a branch (see dvcs - is "clone to branch" a common workflow?). I'd advise you to use repository management software/service such as Rhodecode or Bitbucket, and have each developer have a public fork to follow this workflow:

enter image description here

Finally, read about feature branching and maybe a little about Gitflow (the basic ideas are DVCS agnostic).

Improve this answer
0

I like having local repositories, but don't forget backups. I don't want to leave a lot of work sitting on one computer without backups. However, having my own repository makes me feel freer to try things.

You can push small changes back into development, provided they won't break anything. (Continuous integration and automated test suites help here.) If they're minor code improvements or bug fixes, you want other people to be able to pull them into their repositories.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.