Tag Archives: Best Practices

Subversion Best Practices: Repository Structure

Maintaining a Subversion repository can become a complex task, and implementing the right project layout from the very beginning is crucial. As Subversion doesn’t impose a strict file structure, users are free to tailor Subversion repositories to their project’s needs. Users can organize Subversion on a ‘one project per repository’ basis or create multiple projects within the same repository; and have considerable freedom when it comes to how they use Subversion’s trunk and branches. In this post, we’ll look at some guidelines and best practices on how to keep Subversion files, for users who are embarking on a new project in Subversion.

Multiple Projects: Single Repository vs. Multiple Repositories

In modern software development, it’s normal for teams to be working on multiple projects simultaneously. If this sounds like your organization, the first question you’ll need to answer is: should I set up a single repository for multiple projects, or create one repository per project? Although the experience will be slightly different for each project, there are some general benefits and drawbacks to each approach.

Single Repository

Single repositories are typically suited to organizations managing multiple, small projects that require cross references, cross tracking, etc.

Positives:

    • there is a single location where all the code is stored, even for projects you aren’t directly involved in.
    • ability to reuse common libraries.
    • lack of duplicated maintenance (e.g only one repository needs to be backed up.)
    • the ability to move data between projects more easily, and without losing any versioning information.
    • all projects share the same repository history.
    • typically less administration – new projects can be created without creating a new repository, and without the help of sysadmin.
    • you can delete entire projects without losing the record from Subversion.

 

 

Negatives:

    • Subversion uses repository-global revision numbers which apply to entire trees, not to individual files. The revision number for projects will increase in accordance with the rest of the repository, even if no changes have been made to that particular project.
    • unable to use unified logging (svn log command).
    • branching can be complex when many folders and files are involved.
    • dumping/loading one huge repository can be time-consuming.

 

 

Multiple repositories

These are typically suited to multiple large unrelated projects.

Positives

    • the ability to define different access permissions, for different users.
    • each project repository will have its own revision sequence.
    • the version number is meaningful for all projects.
    • projects have a tendency to increase in size, and numerous large projects on a single repository can become difficult to maintain. It is typically easier to manage large projects with a ‘one repository per project’ approach.
    • can tailor each repository’s structure to suit a project’s unique needs. This can include branching, tagging, naming conventions, etc.

 

 

Negatives:

    • Subversion does not support merging code between projects in different repositories, and the transplanted code will appear in the new repository with no history. This also means you cannot perform merges if you need to temporarily maintain two versions of related code.
    • different projects have different mailing lists, which can be a problem if there’s cross-over between two related, but separate, projects.

 

 

There is also the potential to have more than one repository, and to group related projects within the same repository. This allows related projects to share data, and when new revisions are added to a repository, they are more likely to be relevant to everyone who uses the repository.

Project Layout

Once you’ve decided whether to organize your projects in a single or multiple repository structure, it’s time to plan your project layout. Putting some thought into your layout in the beginning, can help you avoid having to move files around later.


An illustration of how a Subversion Repository evolves using branching, tagging and a code trunk.

Here are some best practices for getting the most out of your project layout:

    • Project root – This is the anchoring point for a project. A repository may contain one project root, or multiple roots, but each project root contains three subdirectories: /trunk, /branches, and /tags. The use of a project root is officially recommended by the Apache Subversion project.
    • Trunk – This is where you should store current release code – only! Don’t muddy the trunk directory with revisions or release names.
    • Branches – Use these to work on significant changes, variations of code etc, without disrupting the current release code.
    • Bug fixing on a branch – Branches should be created to fix major bugs; this allows bug changes to be immediately worked on without disrupting whatever work is currently underway in the trunk/development branches.
    • “Toe in the water” branches – Branches can be used as a code “sandbox” where new technology can be tested without risking the working code. If things go right, the new code can always be merged back into the trunk.
    • Tags – Should be used as “code milestones” providing a snapshot of the code at specific points in its history.
    • Tagging bug fix / development branches – when creating a code or bug fix branch, it’s useful to create a “pre” tag, and a “post” tag after the bug fix or code change has been completed:

 

 

http://10.2.5.2:9880/encom/tags/PRE_authchange_bug9343

http://10.2.5.2:9880/encom/tags/POST_authchange_bug9343


Ready to start a new project with Apache Subversion? Certified open source Apache Subversion binaries can be downloaded from the WANdisco website.

via: http://blogs.wandisco.com/2011/10/24/subversion-best-practices-repository-structure/

Guidance – Branching for each Sprint

metro-visual-studio-2005-128-linkThere are a lot of developers using version control these days, but a feature of version control called branching is very poorly understood and remains unused by most developers in favour of Labels. Most developers think that branching is hard and complicated. Its not!

What is hard and complicated is a bad branching strategy. Just like a bad software architecture a bad branch architecture, or one that is not adhered to can prove fatal to a project. We I was at Aggreko we had a fairly successful Feature branching strategy (although the developers hated it) that meant that we could have multiple feature teams working at the same time without impacting each other. Now, this had to be carefully orchestrated as it was a Business Intelligence team and many of the BI artefacts do not lend themselves to merging.

Today at SSW I am working on a Scrum team delivering a product that will be used by many hundreds of developers. SSW SQL Deploy takes much of the pain out of upgrading production databases when you are not using the Database projects in Visual Studio.

With Scrum each Scrum Team works for a fixed period of time on a single sprint. You can have one or more Scrum Teams involved in delivering a product, but all the work must be merged and tested, ready to be shown to the Product Owner at the the Sprint Review meeting at the end of the current Sprint.

So, what does this mean for a branching strategy?

We have been using a “Main” (sometimes called “Trunk”) line and doing a branch for each sprint. It’s like Feature Branching, but with only ONE feature in operation at any one time, so no conflicts Smile

clip_image001
Figure: DEV folder containing the Development branches.

 

I know that some folks advocate applying a Label at the start of each Sprint and then rolling back if you need to, but I have always preferred the security of a branch.

Like:

  • being able to create a release from Main that has Sprint3 code even while Sprint4 is being worked on.
  • being sure I can always create a stable build on request.
  • Being able to guarantee a version (labels are not auditable)
  • Be able to abandon the sprint without having to delete the code (rare I know, but would be a mess if it happened)
  • Being able to see the flow of change sets through to a safe release
  • It helps you find invalid dependencies when merging to Main as there may be some file that is in everyone’s Sprint branch, but never got checked in. (We had this at the merge of Sprint2)
  • If you are always operating in this way as a standard it makes it easier to then add more scrum teams in the future. Muscle memory of this way of working.

Don’t Like:

  • Additional DB space for the branches
  • Baseless merging between sprint branches when changes are directly ported
    Note: I do not think we will ever attempt this!
  • Maybe a bit tougher to see the history between sprint branches since the changes go up through Main and down to another sprint branch
    Note: What you would have to do is see which Sprint the changes were made in and then check the history he same file in that Sprint. A little bit of added complexity that you would have to do anyway with multiple teams.
  • Over time, you can end up with a lot of old unused sprint branches. Perhaps destroy with /keephistory can help in this case.
    Note: We ALWAYS delete the Sprint branch after it has been merged into Main. That is the theory anyway, and as you can see from the images Sprint2 has already been deleted.

Why take the chance of having a problem rolling back or wanting to keep some of the code, when you can just abandon a branch and start a new one?

It just seems easier and less painful to use a branch to me! What do you think?

via: http://nakedalm.com/guidance-branching-for-each-sprint/