Tag Archive for 'branch'

Subversion Tip of the Week

Tagging and Branching with SmartSVN’s ‘Copy Within Repository’

SmartSVN’s ‘Copy Within Repository’ command allows users to perform pure repository copies, which is particularly useful for quickly creating tags and branches.

To create a repository copy within SmartSVN:

1) Open the ‘Modify’ menu and select ‘Copy within Repository’.

2) From the ‘Copy From’ dropdown menu, select the repository where the source resides.

3) In the ‘Copy From’ textbox, specify the directory being copied. In ‘Source Revision,’ tell SmartSVN whether it should copy the HEAD revision (this is selected by default) or a different revision. Use the ‘Browse’ button if you need more information about the contents of the different directories and/or revisions that make up your project.

copy within repo

4) Select either:

  • Copy To – source is copied into the ‘Directory’ under the filename specified by ‘With Name’

  • Copy Contents Into – the contents of the source are copied directly into the ‘Directory’ under ‘With Name.’

5) Enter the copy’s destination in the ‘Directory’ textbox. You can view the available options by clicking the ‘Browse’ button.

6) Give your copy a name in the ‘With Name’ textbox.

7) The copy is performed directly in the repository, so you’ll need to enter an appropriate commit message.

8) Once you’re happy with the information you’ve entered, hit ‘Copy’ to create your new branch/tag.

Try SmartSVN Professional free today! Get a free trial at http://www.smartsvn.com/download.

All About SVN Copy

Apache Subversion’s commit command allows you to quickly create a copy of item(s) at both the working copy and the repository level. It’s most commonly used in creating branches.

In this tutorial, learn how to use the ‘svn copy’ command to copy file(s) in the working copy and the repository, alongside options such as copying items at specific revisions.

…in the Working Copy

The ‘svn copy’ command allows you to create a copy and place it in a new location within the working copy by running the command followed by the location of the item(s) you’re copying and the new location.

In this example, we’re creating a copy of the ‘Release3’ folder and placing it inside the ‘Releases’ directory.

svn copy (working-copy-path)/item-being-copied (working-copy-path)/item-being-created

svn copy

Check your working copy and you’ll see the file (‘Release4’) has successfully been created. Remember, this is a local change so you’ll need to perform an ‘svn commit’ to share it with the rest of your team.

svn copy 2

….in the Repository

Alternatively, you can create copies at the repository level. This change will automatically create a new revision so you’ll need to provide a log message alongside the ‘svn copy’ command.

svn copy (repository-URL)/item-being-copied -m “log message” (repository-URL)/item-being-created

svn copy 3

You can also copy item(s) as they existed in particular revisions, by specifying a revision number:

svn copy -r(revision-number) (repository-URL)/item-being-copied -m “log message” (repository-URL)/item-being-created

If no revision number is given, Subversion will default to HEAD.

 

svn copy 4

….Or Both 

Finally, you can copy item(s) between the working copy and the central repository. Note that when you’re copying to/from the repository, the usual rules apply: A log message is required, and the repo will copy the HEAD revision unless instructed otherwise.

In this example, we’re creating a copy of the “Release3” folder in the working copy and adding it to the repository as a folder called “Release5.”

svn copy 4

Want more advice on your Apache Subversion installation? We have a full series of SVN refcards for free download, covering hot topics such as branching and merging, and best practices. You can find out more at www.wandisco.com/svnref

Intro to Tagging in Subversion

What are Tags?

In Apache Subversion, branches and tags are essentially the same thing: a copy of an existing folder and its contents, in a new location within the same repository. The key difference is the way the user handles these folders.

Tags should be used as “cold milestones” that provide a snapshot of your project at a specific point in time. Although a revision already acts as a snapshot, tags allow you to give them a more human-readable name (“Release 7.0” rather than “Revision 24973.”) Tagging also allows you to take snapshots of specific sections of the repository.

Why Should I Create a Tag?

Creating a tag uses the ‘svn copy’ command, followed by the section of the repository that’s being tagged, and the location where the new tag will reside. As ever, don’t forget to leave a log message:

svn copy -m “useful log message”(URL) (location of new tag)

In this example, we are creating a new tag called ‘Release1,’ by copying all the files currently in the trunk.

tags

Tip. Whether you are creating a branch or a tag, it’s worth putting some thought into your naming strategy. A coherent naming strategy allows others to get an insight into what development work is happening in which branch/tag, at a glance.

tags2

Looking for an easy-to-use cross platform Subversion client? Claim your free 30 day trial of SmartSVN Professional by visiting: www.smartsvn.com/download

Subversion Tip of the Week

Deleting a Branch

When something is deleted from Apache Subversion, it only disappears from the revision where it was deleted and all subsequent revisions. Deleting branches in Subversion has no effect on repository size, as it still exists in all previous revisions and can be viewed or recovered at any time. So, the question is why would you ever delete a branch?

1) House-keeping – regularly deleting branches reduces the clutter in the branches directory, and makes browsing the repository less confusing. When all abandoned branches are routinely deleted, a quick glance at the branches directory can tell you which branches are still active.

2) Following a merge – in some situations where you’ve finished working on a branch and merged the changes into the trunk, the branch may become completely redundant and you should consider deleting the branch to reduce clutter in the repository.

3) Following reintegration – the ‘–reintegrate’ command allows merging from a branch to the trunk, by replicating only the changes that are unique to that branch. A ‘–reintegrate’ merge uses Subversion’s merge-tracking features to calculate the correct revision ranges to use, and checks to ensure the branch is truly up-to-date with the latest changes in the trunk. These checks ensure the reintegration will not override work other team members have committed to the trunk.

Once a ‘–reintegration’ merge has been performed, the branch shouldn’t be used for development as any future reintegration will be interpreted as a trunk change by Subversion’s merge tracking. This will trigger an attempt to merge the branch-to-trunk merge back into the branch. To avoid this, the reintegrated branch should be deleted.

How to Delete a Branch

To delete a branch, run the ‘svn delete’ command alongside the URL of the branch and an appropriate log message. In this example, we are deleting the ‘bug fix branch.’

delete branch

Subversion Tip of the Week

Intro to Branching in Subversion

For developers who aren’t familiar with version control, getting to grips with Apache Subversion’s branching functionality can be daunting. But, when used correctly, branching can be one of Subversion’s most powerful and useful features.

What is a Branch?

Put simply, a branch is a line of development that exists independently of another line.

intro to branching

 

Every project is different, but there are some common reasons why developers might choose to create a branch:

  • To isolate development – This is often called a ‘concurrent development branch,’ and is the most common reason to create a branch.
  • To experiment with new technology – Branches can be used to test a new technology that might not necessarily become a part of the main branch. If the experiment works out, the new code can easily be merged into the trunk.
  • To tag a project and keep track of released code – This is often called a ‘release branch.’ Upon completing a release, it is a good idea to create a branch and tag it with a name that is meaningful to that release (for example, “release-2.0.”) This serves as an easy-to-retrieve record of how your code looked, in a certain release.
  • To fulfil a particular customer’s need – This is often called a ‘custom branch,’ and is useful when you need to modify your project for a particular customer’s requirements.

Creating Your First Branch

To create a new branch, use the ‘svn copy’ command followed by a log message (-m) and the URL of both the resource being branched, and the location where you want to create your new branch:

svn copy -m “Creating a new branch” folder-being-branched location-of-new-branch

In this example, we are creating a new branch called ‘bug fix branch’ inside the ‘branches’ folder, that will contain all the files in the trunk:

branching-from-the-command-line

Looking for a cross-platform graphical client for Apache Subversion? Claim your free 30 day trial at www.smartsvn.com/download

How to Create a Branch and Tag in Apache Subversion

In Apache Subversion branches and tags are effectively the same thing – a copy of an existing folder and its contents, in a new location within the same repository. The main difference is the way the user handles branches and tags:

  • Branches – these should be used to work on significant changes, variations of code, and bug fixes.
  • Tags – should be used as “code milestones” that provide a snapshot of your project at a specified point.

In this post, we’ll show you how to create a branch, before providing an example of creating a tag.

Creating a Branch

To create a new branch, use the ‘svn copy’ command followed by a log message (-m) and the URL of both the resource being branched, and the location where you want to create your new branch:

svn copy -m “Creating a new branch” folder-being-branched location-of-new-branch

In this example, we are creating a new branch called ‘bug fix branch’ inside the ‘branches’ folder, that will contain all the files in the trunk:

Creating a Tag

Creating a tag uses exactly the same command, although it is good practice to create a dedicated ‘tags’ folder, where you can store all your tags.

In this example, we are creating a new tag called ‘Release1,’ again by copying the files currently in the trunk.

Tip. Whether you are creating a branch or a tag, it’s worth putting some thought into your naming strategy. A coherent naming strategy allows other team members to get an insight into what development work is happening in which branch/tag, at a glance.

Subversion Tip of the Week

Creating Your First Apache Subversion Branch

The concept of branching can strike fear into the hearts of Apache Subversion users, but when used correctly Subversion’s branching functionality is a powerful tool. In this week’s tip, we provide an intro to branching, by showing you how to create your first branch.

There are several ways to create a branch, but the ‘svn copy’ command is useful as it retains the folder’s history prior to the branch being created.

Tip. While it is possible to manually create a new file, copy your files over by hand and then commit this to the repository, this new branch will have no history prior to its creation.

To create your first branch in Subversion, use the ‘svn copy’ command followed by the file(s) you want to copy to the branch, and the location and filename of the branch you wish to create:

svn copy (working-copy-path/trunk) (working-copy-path/branches/name-of-branch)

In this example, we are copying all the contents of the trunk into a branch called ‘bugfix branch 1’

Now when you explore your working copy, you will notice a new file has been created – this is your new branch!

Tip. In Subversion branches and tags are effectively the same thing – a copy of an existing folder and its contents, in a new location within the same repository. The difference is all in the way you handle branches and tags, so it’s important to work out a sane project structure before you start branching.

Subversion Live 2012: Branching and Merging

Branching and merging is one of the issues Apache Subversion users seem to encounter the most issues with, and with that in mind we designed the Subversion Live 2012 programme to include plenty of best practices, tips and tricks on branching and merging.

Subversion Live 2012 attendees had the opportunity to attend two breakout sessions on branching and merging during the second day of the conference. The first breakout, ‘Branching and Merging Best Practices’ was conducted by WANdisco’s Director of Subversion Training, Mike Lester.

Mike’s session covered essential know-how for mastering branching and merging in Subversion, including factors that should be taken into account when planning your branching strategy, such as how to handle releases and bug fixes, and what changes require a branch. Mike advised that these decisions should be clearly laid out in a Policies and Procedures document.

He also shared some best practices for tracking branch usage, which included controlling where branches can be created and implementing a clear naming convention for your branches. On the merge tracking side of things, he explained how svn mergeinfo can be used to track merges.

Mike Lester’s session concluded with a Q and A session, where attendees had the opportunity to share their own branching and merging strategies, and get feedback from both Mike Lester and the other attendees.

After lunch, delegates had the opportunity to attend a ‘Merge and Performance Improvements’ session, led by Julian Foad. Julian is the lead developer for enhancements to Subversion’s merge capabilities at WANdisco, and his session delved into greater depth regarding the upcoming reintegrate merge overhaul in Subversion 1.8.

Julian explained that in Subversion 1.8, users will no longer have to specify that they are performing a reintegrate merge. This will make merging quicker, easier and less error-prone than in previous releases.

In Subversion 1.8, a branch will no longer become redundant after a reintegrate merge has been performed, so developers will be able to continue using the branch.

Julian also went into detail about how these merge changes will impact the SVN help command, essentially making the ‘svn help merge’ output more concise.

Read all about Subversion Live 2012, with our recaps of Day One and Day Two, and an in-depth look at the Subversion Live Keynote and the What’s Coming in SVN 1.8: Overview session. You can also check out Subversion Live 2012: Your Feedback to see what people are saying about the conference.

Subversion Tip of the Week

Tagging Your First Release in Subversion

Apache Subversion remembers every change made to its files and repositories, giving you the option of rolling back to previous revisions when disaster strikes. To make rolling back easier, it’s good practice to explicitly label your project at certain points in the development effort (for example “Release 1.0.”) This is where tags come in.

Tags allow you to create a snapshot of your project, with a human-friendly label. Creating a tag follows the same process as creating a branch, although to avoid confusion it is a good idea to create a dedicated ‘tags’ directory. To create a tag, use the ‘svn copy’ command:

svn copy (working-copy-path/trunk) (working-copy-path/tags/name-of-tag)

In this example, we are copying the entire contents of the trunk to a folder called ‘Release 1.0’ in the ‘tags’ directory.

Now when you explore your working copy, you will see a new folder in the ‘tags’ directory.

You have just created your first tag!

Tagging Tips

Every project will be different but there are some common scenarios where tags can come in handy:

    • At a stable point during development.
    • To mark a release, or a patch.
    • Just before a complicated merge.

 

Note, as tags are supposed to be a snapshot of your project at a certain point in time, it is important not to modify the tag.

Merging in Subversion: Merge a Range of Revisions

Along with branching, merging is the issue that regularly causes Apache Subversion users the most confusion – but merging needn’t be complicated! In this post, we’ll show you how to successfully perform a merge in less than ten steps, using TortoiseSVN’s ‘merge a range of revisions’ option.

Tip. Two common scenarios where this type of merge comes in handy are sync’ing a development branch by applying all the latest changes from its ‘parent’ branch; and cherry-picking specific changes to add to your release branch.

To merge a range of revisions:

1) Right-click on the file you wish to merge and open the ‘TortoiseSVN’ menu.

2) Select ‘Merge’ from TortoiseSVN’s sub-menu.

 

 

 

 

 

 

 

 

3) Select the ‘Merge a Range of Revisions’ option.

 

 

 

 

 

 

 

 

 

4) In the ‘Merge’ dialog, select the desired URL using the “….” button.

5) Either specify the revision numbers you wish to merge, or leave the revision range blank to merge all outstanding changes from the specified source.

 

 

 

 

 

 

 

 

 

6) Once you have entered all the relevant information, click ‘Next.’

7) TortoiseSVN will open the ‘Merge options’ dialog. In most instances, the default settings can be used.

8) Select ‘Merge’ to perform your merge!

Need more info on branching and merging in Subversion? This year’s Subversion Live series of conferences features a session dedicated to Branching and Merging Best Practices. Visit http://www.wandisco.com/svn-live-2012 to find out more.