source control philosophies/techniques

Does anyone have any good links about how to most effectively use source control systems, namely Perforce?  We use it where I work, but no one knows all that much about it.

For example, one philosophy I read is that the head revisions should always be spanking clean and tested, while development occurs in branches, which is periodically integrated with some sort of testing process.

This seems to contradict what's on the Perforce website, where it seems to say that the mainline is for development and releases are branches.

I have heard of teams using a branch for every engineer on the team.  I have heard of teams using no branches at all.

I have browsed the website, but I have not worked on that many teams so I'm looking for input of other philosophies/techniques that have worked for people, and maybe some that definitely haven't.  I know every team has different requirements, but I think it would be educational to learn both what policies were followed and why you followed them.  What's on the P4 website is good, but it's a little too abstract.  Some anecdotal evidence would be enlightening.

Roose
Thursday, March 18, 2004

Using the head revision for development and branches for releases is just a question of your point of view. For the repository, it's just a bunch of branches, you have to define WHICH branch is the "release" and which is the "development" branch. If you're producing packaged software for third parties, your view on the repository will probably have one large trunk with releases branching off for testing and so you can maintain them later. In the meantime, development continues along the main trunk.

If you're not developing packaged software, but instead are providing somekind of service or plattform -- a web store, stock ticker, payment provider, etc.-- you'll probably view the repository as a central trunk culminating in the version that's currently in production with development and testing branching off.

It doesn't matter either way, though. What determines if development takes place in the branches or on the "head" is just your perception of the repository.

That said, there's still plenty of ways to screw up a repository. Make sure everyone on the team understands your scheme of branching and knows how to operate the functions of the version control software needed to implement that scheme.

-tim

a2800276
Thursday, March 18, 2004

We are currently implementing Vault so I spent some time last week looking for this same information and found this http://www.cmcrossroads.com/bradapp/acme/branching/ site, it might be useful to you as well.

Obviously some of those techniques are more heavyweight that what we were after, so we are going with the following (I will admit we aren't sure how it will turn out but at the moment it seems good to us):

$/trunk/<product>
$/customisations/<company/customer>
$/releases/<product>/<version>

And what we plan to do (and have already done some of is):

Do all work in $/trunk/ as this is what we have been doing in VSS all this time, "share" the common files into the appropriate customisations folder, and branch those files that are going to be changed for the customisation.

We then plan to use the Vault "snapshot" feature to make a snapshot of each released version in the $/releases folder.


On a sidenote, does anybody have any good ideas on how to do branching/sharing with Visual FoxPro databases?

Our applications database is stored in Vault/VSS and we have to branch it for each customisation, even if we are adding fields in only one table - the reason is that when you add a field to a VFP database table, the corresponding DBC files is changed as well which means we can't just share/branch the individual tables.

Chris Ormerod
Thursday, March 18, 2004

Can FoxPro deal with SQL that creates tables and such? If so I would create a script which creates and populates the db you want and put that under source control instead.

Thursday, March 18, 2004

Perforce has a best practices document on their
site.

The key issue is how many products do you
develop simultaneously. A product can be different
versions of the same product or even different products
on the same release cycle.

If there is only one product then your main branch
can easily always be the current release of the
product under development.  You can pull feature
branches for complex features with a longish development
time and many people involved, or if you are not
really sure when a feature will go into a release.

Keep these branches to a minimum because it complicates
development because you must sync and integrate.

Branch for each each product release.

If you have multiple products i would have a main
branch for each. Common code can be kept in
another independent product and used in other
products like 3rd party libraries instead of building
from source.

If your products are really independent then you
can get away with one branch for them all.

son of parnas
Thursday, March 18, 2004

Branch when you have to.
Do not branch when you do not have to.

That sounds like tautology, but apparantly that's not as obvious as it should be to many people.  The point is that there are moments when you *must* create a branch, such as to fix a bug from product release V4 to make a V4.1 without picking up the new V5 feature changes in that file.  Whenever you *can* procede without creating a branch, you *should*.  Purposeless complexity is stupid.

Always ensure that you can reproduce any important build and identify which files were in that build.  Ensure this by dogmatically performing important builds by retrieving with a label (or whatever equivalent your revision tracking product provides.)  If you're not recording the contents of released builds -- whether released to testing or to a customer -- you're being sloppy.  If you are labeling builds and verifying the truth of the labels by building only from labels, then you needn't give a rat's ass about what is at the tip of a file's revision tree because you'll never do a "get" of the tips. So the "always branch" philosophies prove silly.

(Also beware that there are "specialists" in source code management who will sell complicated revision tracking snake oil.  Complicated approaches create jobs for these people.  Managing source code is a required competence for a programmer, and an important part of programming well.  Source code management should not become an excuse to invite into the process people who are not programmers and therefore cannot deeply understand how code evolves.)

veal
Thursday, March 18, 2004

I have an ignorant/dumb question to ask.  Do people typically use source control software on home projects on which they are the only developer?  I'm starting to work on a project and am wondering if I should start using some sort of source control

Une Ternal
Thursday, March 18, 2004

Une,

I would say yes, and Perforce and Vault both have free versions for 1 or 2 developers.

Anonymous,

FoxPro can handle a script to create the tables, but our default database has loads of records that need to be in the database. And we tried using a script to store that in VSS but then when we added a field to a table we need to go to all the INSERT statements and alter them. Is there a better way of doing this part of it then?

Chris Ormerod
Thursday, March 18, 2004

Any suggestions for background reading for a SINGLE developer working on multiple (20) programs?

Most of the SC literature is dealing with merging changes from different users, preventing them from walking all over each other's code, etc.

That's not my situation.

Mr. Analogy
Friday, March 19, 2004

  Recent Topics

  Fog Creek Home