SVN Best practices

www.dreamix.eu

Angel GruevDreamix ltd

About Angel

Chief Technology Officer @Dreamix

● Software Architecture

● Project Management

● Oracle Technologies

● Education

● Bikes

● Snowboarding

Copy-modify-merge

The Problem: The solution:

www.dreamix.eu

SVN Revisions

❖ Commit – changes to the server state

❖ Every commit results in a new Revision➢ Every revision has its unique identifier number

www.dreamix.eu

SVN Layout

❖ Typical (sane) repository layout<Project Root> ( MyProjectName/)

- trunk

Contains the latest working (development) version

of the project.

- tags

Contains named revisions

- branches

Contains so called branches from the main development line.

www.dreamix.eu

Basic actions

● Checkout

● Commit

● Add

● Update

● Delete

● Revert

● Rename

● Merge

● Lock/Unlock

www.dreamix.eu

Merge using Tortoise SVN

www.dreamix.eu

Best practices

❖ Commit logical changesets➢ make sure your change reflects a single purpose

❖ Use the issue-tracker wisely➢ Two way links between SVN and issue-tracker

➢ If possible, refer to a specific issue ID in every commit log message.

➢ When appending information to an issue (to describe progress, or to close the issue) name the revision number(s) responsible for the change.

❖ Always write a comment on your commit

❖ Trunk must be always compile-able and work-able

❖ SVN:ignore resulting artifact of the build process➢ Classes/Bin directory

❖ Use standard coding formats

❖ Use SVN wisely to help you in multy-environment (DEV, QA, UAT, PROD)➢ Always tag every deployment and document it

www.dreamix.eu

Versioning of the applciation

❖ Think of a good versioning number➢ The X.Y.Z_Revision approach

➢ Change in X – Major change. Potential backward incompatibility

➢ Change in Y – Minor feature and bigfix is introduced

➢ Change in Z – Small changes, mostly bugfix releases

www.dreamix.eu

Branching

❖ The Never-Branch system➢ Pros: Very easy policy to follow➢ Cons: Chaotic development, code could be unstable at any time

❖ The Always-Branch System➢ Pros: /trunk is guaranteed to be extremely stable at all times➢ Cons: Requires users to do lots of extra merging.

❖ The Branch-When-Needed System➢ 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

www.dreamix.eu

Common Branching Patterns [1]

❖ Normal app lifecycle - code, test, release➢ Developers keep writing new features while previous release is being

tested

➢ Support old releases

www.dreamix.eu

Common Branching Patterns [1]

❖ Release branches➢ Developers commit all new work to the trunk

➢ The trunk is copied to a “release” branch

➢ Teams continue to work in parallel

➢ The branch is tagged and released

➢ The branch is maintained over time

www.dreamix.eu

Common branching patterns [2]

□ Feature Branches■ It's a temporary branch created to work on a complex change without interfering with the stability of /trunk.

■ Feature branches are born, used for a while, merged back to the trunk, and then ultimately deleted

□ When do we create a feature branch

□ Regularly merge changes from trunk to the branch

www.dreamix.eu

Merging with TortoiseSVN

www.dreamix.eu

Merging with TortoiseSVN

□ Merge a range of revisions

www.dreamix.eu

Best practices [cont]

❖ Keep your SVN clean and tidy➢ Delete branches that were successfully merged or reintegrated

❖ Use it to check differences between version➢ Of the whole application

➢ Of a single resource or directory

❖ Very helpful for doing code reviews

www.dreamix.eu