Subversion

From JazzTeamWiki
Jump to: navigation, search
Language: English  • русский

knowledge

  • revisions
    • to be linked to code changes
  • trunk
    • head of development
  • tags
    • human understandable revisions
    • to be read from
  • branch
    • to make active development
    • it is possible to rename branches e.g. brach_early_development_not_used when they are not used
    • could be useful when supporting old version of software for someone request
    • when there are newcommers at project which work at branch version and then project manager makes a merge, then trunk would become very stable all the time - no broken builds at all


Three approaches for working with subversion

Taken from [Apache subversion practices]

The Branch-When-Needed system
	Users commit their day-to-day work on /trunk.
	Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.
	Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.
	Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.
	Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is somewhat rare.
	Cons: Adds a bit of burden to users' daily work: they must compile and test before every commit.

The Always-Branch system
	Each user creates/works on a private branch for every coding task. 
	When coding is complete, someone (original coder, peer, or manager) reviews all private branch changes and merges them to /trunk.
	Pros: /trunk is guaranteed to be extremely stable at all times. 
	Cons: Coders are artificially isolated from each other, possibly creating more merge conflicts than necessary. Requires users to do lots of extra merging.

The Never-Branch system
	Users commit their day-to-day work on /trunk.
	Occasionally /trunk "breaks" (doesn't compile, or fails functional tests) when a user begins to commit a series of complicated changes.
	Pros: Very easy policy to follow. New developers have low barrier to entry. Nobody needs to learn how to branch or merge.
	Cons: Chaotic development, code could be unstable at any time.

tips

svn has atomic commits

it is good to have atomic logical commit - related to certain task, or logical change of application

it is good to link revisions to issue id and vice versa - in commit messages

physically tags = branches = release