The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Codeline management

Hi guys,

The company I work for is in the process of moving to multiple projects based off of the same core 'engine' software and tools (which are continuously evolving). Although we use Perforce which is known for it's branching and integration support, we have not really used branching much for handling 'policy changes' within a single project (ie. making a release build branch for a milestone).

I've been reading Practical Perforce ( http://www.amazon.com/exec/obidos/tg/detail/-/0596101856?v=glance ) which is quite enlightening, but it focuses on the mainline model and doesn't really get into multiple project support.

Would anyone be willing to share their own experience with this subject or point me to some online references or books?

Thanks!
Adriano Bertucci Send private email
Friday, September 08, 2006
 
 
It never really works out, so be prepared for suckiness.

The biggest issue to consider is how parallel with the projects really be?

If they have completely different customers, release schedules, QA, etc then it would be best to create a micro core that is really common to everything and doesn't change much. Then the macro core is built on top of the micro core. The micro core is developed on separate branch and is imported into your development branch like a third party library. In this scenario let the micro core be developed completely independently in the same branch as the product. You can move bug fixes/features between products as needed. You don't want requirements of one product to impact the schedule of another.

If the micro core and the macro core are really pretty common accross all products then I would develop it in its own branch with its own release schedule. Each separate product would submit bugs and feature requests to the responsible group and release trains would need to be synced. Again, you would import the core into your product branch like any other thrird party library.
son of parnas
Saturday, September 09, 2006
 
 
The best source control references I have so far read are Eric Sink's "Source Control HOWTO" at http://software.ericsink.com/scm/source_control.html
and "Software Configuration Management Patterns" by Berczuk and Appleton.  Hope that helps some.
Jesse Send private email
Sunday, September 10, 2006
 
 
++ Eric Sinks' articles.

My only wish is that he'd make a downloadable version in PDF format, so I could get to it easier.

Ken
KenW
Tuesday, September 12, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz