When multiple release versions
must be supported, the production-branch model is strong, as multiple branches
can be created. This can be useful on occasion even in web applications; for
example, a large feature release can be staged as a ???beta??? to a subset of users.
If the beta is long-lived, it is useful to create a branch so that development can
continue independently.
* http://www.orcaware.com/svn/wiki/Svnmerge.py
Version Control | 303
This model is a slight deviation from the ordinary non-web software development
model. In that model, features are developed in the trunk, stable work
toward a release is kept in a branch, and finished releases are tagged by copying
them to the tags directory. The Rails framework itself uses that model.
Feature branches
This is essentially the opposite of the production-branch model. One branch is
created for each new feature to be deployed. The trunk is always expected to be
stable and represents the latest stable version of the software.
Some prefer the feature-branch model over the production-branch model for web
applications, as it compartmentalizes features and isolates them from one another
during development and testing. It supports the single-deployment-environment
paradigm, but it is difficult to support multiple releases under this model.
Developer branches
Again, the trunk is a stable codebase. Each developer has his own branch that he
can use as his ???sandbox??? for developing and testing features.
Pages:
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460