6

I'd like to have some suggestions about using code repository. I don't need to know how to check out or how to check in or how to create a branch. What I need to know is, how to maintain the repository tree or how to structure it for optimal usage.

For example, for a given project, when to create a branch? Where to create a branch with respect to the project's location? What should be done when one or more than one developer are working on same project but different features? When to merge? Where goes the bug fix? How the QA team should checkout a specific version? Etc.

Improve this question
2
  • 4
    You may want to specify if you want anwers for centralized, decentralized or both kind of versionning systems. There is a huge differences between them, especially regarding branches. Commented Feb 16, 2011 at 16:48
  • @Matthieu: my purpose of the post is to get an idea of all those features (i don't know about centralized/decentralized systems) and when to use them, whatever the system is (centralized/decentralized). i want to learn the methods. Commented Feb 16, 2011 at 16:53

5 Answers 5

Reset to default
4

In case you are using git I would recommend you to read this post "A successful Git branching model"
However if you are not using git I believe you still can find few very interesting ideas in there.

Improve this answer
5

A good starting point would be this guide and handbook of best practices, which doesn't apply only to the Perforce SCM.

Then there's a herd of similar questions on stackoverflow.com.

Improve this answer
2
  • Many of those are best practices for any CM system. Commented Feb 16, 2011 at 18:27
  • @Brian: Yes, my point exactly. And the question being generic, I think that was suitable. Commented Feb 17, 2011 at 0:39
2

It's a good question, but there is no silver bullet here. Let me share some personal guidelines that seem to hold themselves in good stead over the last decade:

  1. It's a good idea to maintain separate production and development branches. The production branch is your immediate bread and butter, this is where hot fixes go -- you keep production and development in different branches so that the usual developer check-ins for some future release never screws your current customer commitments.
  2. Have a single production branch. Don't have customer specific production branches (unless you are getting too much sleep and want to stay awake at nights)
  3. If developers or groups are working on disparate ideas, have development specific branches.
  4. You merge branches well in advance (2-3 weeks) before a major release. I usually merge the changes into production, but there are people who make a new production branch with every major release so that's your call there.
Improve this answer
1

Conceptually, most source control systems are similar. There are exceptions - as has been mentioned, branching models tend to be rather different in distributed systems compared to the non-distributed variety.

Joel Spolsky wrote a useful introduction to the Mercurial way of doing things: Hg Init. It's worth reading, even if you're not planning to use Mercurial.

Improve this answer
1

I tend to avoid development branches as much as possible. This forces early merging of new code. Commit early; commit often. This fits well with a continuous or frequent build environment.

Development branches are best kept for experimental or architectural changes which have may not be accepted. Merging them back into development can be problematic.

I branch each production release from development. Changes on the branch are managed. They almost always need to make their way back to development. However, production may get a quick fix and a larger fix may go into development.

Some projects to a branch per fix, and then merge them into the development code individually. This gets to be a problem if you have overlapping changes. It is helpful, if you decide to back out a committed change.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.