Subversion branching and merging
Subversion does not actually have a built-in branching or tagging mechanism as
such; all branches and tags are simply copies of part of the directory tree. Subversion
creates cheap copies using copy-on-write semantics; data is written to disk only when
the copy is actually changed. The amount of extra information required to maintain
a branch is roughly proportional to the difference between the branch and its parent.
This characteristic has some drawbacks, though. Subversion 1.4 has very primitive
merging support. It does not keep track of when branches were created or merged,
and does not prevent a change from being applied twice. Most developers who do at
least a moderate amount of merging use svnmerge.py,* which keeps track of this
metadata in Subversion properties.
There are many different paradigms for how branches are used. Here are some of the
most common ones for web development:
Production branch
The trunk is used for ongoing development. When a feature is fully developed
and tested, it is merged into the production branch and deployed. This style is
well suited to web applications, which tend to have a single development team
working on one feature package at a time. Urgent production defects can be
fixed in the production branch without disturbing feature work, and later can
be merged into the trunk.
For typical web applications, there is only one release branch, as there is only
one version of the software running at a time.
Pages:
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459