He will either
merge code into the trunk himself or submit the changesets to be integrated by
one person. Often, this is found in large teams, as it integrates well with a formal
code review process.*
If you have a large enough team that developer branches are necessary, you may
find yourself passing around and manually applying patches way too often. In
that situation, it may be worthwhile to consider moving to a distributed version
control system such as Mercurial or Bazaar.
Of course, the appropriate model will vary from project to project. Do not feel constrained
by these models. The trunk, branches, and tags directories are only the traditional
conventions used by Subversion developers. You could just as easily set up
features, production, and snapshots if it suited your fancy.
Mercurial branching and merging
Branching under distributed version control systems such as Mercurial is much more
natural. Any Mercurial repository is automatically a branch, because any repository
can pull changes from and push changes to any other repository, even between two
different directories on the same filesystem. Thus, the standard branching method
under Mercurial is to clone an entire project to a new directory, make the changes,
and then use hg pull to retrieve and merge the changes from a branch when needed.
As an example, suppose we are changing an application??™s color scheme and want to
branch to keep the color-related changes together while doing other development.
Pages:
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461