Tag Archive for 'sherpa'

Subversion Tip of the Week

An Apache Subversion working copy can be created quite simply by running the ‘svn checkout’ command. However, sometimes you’ll want to have more control over the contents of your working copy; for example, when you’re working on a large project and only need to checkout a single directory.

In this post, we share two ways to get greater control over your checkout commands.

1. Checkout a particular revision

By default, Subversion performs a checkout of the HEAD revision, but in some instances you may wish to checkout a previous revision, for example when you’re recovering a file or directory that has been deleted in the HEAD revision.

To specify a revision other than HEAD, add the -r switch when performing your checkout:

svn checkout (URL) -r(revision number) (Location)

In this example, we are performing a checkout of the project as it existed at revision 10.

customizing working copy

2. Performing Shallow Checkouts

A standard Subversion checkout copies the entire directory, including every folder and file. This can be too time-consuming if you’re working on a large project, or too complicated if your project contains many different branches, tags and directories. If you don’t require a copy of your entire project, a ‘shallow checkout’ restricts the depth of the checkout by preventing Subversion from descending recursively through the repository.

To perform a shallow checkout, run the ‘svn checkout’ command with one of the following switches:

  • –depth immediates: checkout the target and any of its immediate file or children. This is useful if you don’t require any of the children’s contents.

  • –depth files: checkout the target and any of its immediate file children.

  • –depth empty: checkout the target only, without any of the files or children. This is useful when you’re working with a large project, but only require the contents of a single directory.

In this example we are performing a shallow checkout on a ‘bug fix branch’ located within the branches folder, and specifying that only the immediate file children should be included (–depth files):

customizing working copy 2

Looking for a cross-platform Subversion client? Get a free trial of SmartSVN Professional at www.smartsvn.com/download

Subversion Tip of the Week

Apache Subversion supports the creation and use of ‘patches’ – text files containing the differences between two files. Patches specify which lines have been removed, added and changed, and are particularly useful when you don’t have write access to a repository. In these instances, you can create a patch file showing the changes between a file as it exists in the repository, and the version in your working copy. Then, you can create a ticket and attach your patch file for someone with repository write access to review and commit the accepted changes to the repository.

To create a patch file, you first need to review the differences between the specific files/revisions you are targeting using the ‘svn diff’ command. In this example, we are examining the differences between the version of the project in our working copy and the central repository.

tip of the week

If you’re satisfied with the differences ‘svn diff’ has identified, run the following command to create a patch:

svn diff > patch_name.diff

tip of the week 2

All the changes will now be written to a patch on your local machine.

tip of the week 3

You can now send this patch to a user who does have write access to the repository.

Creating a Patch Between Revisions

Alternatively, if you want to create a patch containing the differences between two revisions, run the following command:

svn diff r:(revision)(revision) (working-copy-location)

Followed by:

svn diff > patch_name.diff

Again, this patch file can now be submitted to someone with write access.

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

Subversion Tip of the Week

SVN Revert

Apache Subversion’s ‘svn revert’ command allows you to discard local changes on a file or directory and replace it with the version in the repository. This saves you the overhead of performing a fresh checkout, and is also helpful when you need to quickly resolve a conflict.

To revert the changes on a single file, run the ‘svn revert’ command followed by the file path:

svn revert (working-copy)/filename

svn revert

It’s also possible to revert all the changes within an entire directory using the –depth=infinity switch. When this switch is added, any files that have been changed within the specified directory are replaced with their repository equivalent:

svn revert –depth=infinity (working-copy)

svn revert infinity

Useful Additional Commands

  • svn status

Before discarding your local changes, you may want to review exactly which files have been altered at the working copy level by using the ‘svn status’ command:

svn status (working-copy-path)

svn status

  • svn diff

The ‘svn diff’ command prints all the changes that have been made to human-readable files within the working copy, which is useful for identifying the file(s) you want to revert. Each line is prefixed by a character representing the nature of the change:

  1. + Line was added
  2. – Line was deleted
  3. A blank space represents no change

To run ‘svn diff’ enter the following command:

svn diff (working-copy-path)

svn diff

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

SVN Import

There are two main options when you need to add new file(s) to your Apache Subversion project: the ‘SVN Add’ command and ‘SVN Import.’ The advantage of performing an ‘SVN Import’ is that:

  • ‘SVN Import’ communicates directly with the repository, so no working copy or checkout is required.
  • Your files are immediately committed to the repository, and are therefore available to the rest of the team.
  • Intermediate directories that don’t already exist in the repository are automatically created without the need for additional switches.

‘SVN Import’ is typically used when you have a local file tree that’s being added to your Subversion project. Run the following to add a file/file tree to your repository:

svn import -m “log message” (local file/file tree path) (repository-URL)

In this example, we’re adding the contents of the “Release2” folder to the repository, in an existing ‘branches’ directory.

svn import 1

As already mentioned, intermediate directories do not need to exist prior to running the ‘SVN Import’ command. In this example, we’re again importing the contents of ‘Release2,’ but this time we’re simultaneously creating a ‘Release2’ directory to contain the files.

svn import create new folder

If you check the repository, you’ll see a new ‘Release2’ directory has been created. The contents of your ‘Release2’ file tree are located inside.

ubersvn import

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

Subversion Tip of the Week

Getting Help With Your Subversion Working Copy

When it comes to getting some extra help with your Apache Subversion installation, you will find plenty of documentation online and even a dedicated forum where SVN users can post their questions and answer others. However, Subversion also comes with some handy built-in commands that can show you specific information about your working copy, files, directories, and all of Subversion’s subcommands and switches. This post explains how to access all of this information from the command line.

1) SVN Help

One of the most useful features of command line Subversion is the instant access to its built-in documentation through the ‘svn help’ command. To review all of the details about a particular subcommand, run:

svn help (subcommand)

In the example below, we’ve requested information on the ‘unlock’ subcommand. The printout includes all the additional switches that can be used in conjunction with ‘svn unlock.’

svn help unlock

Alternatively, if you need to see a list of all the available subcommands, simply run ‘svn help.’

svn help

2) SVN Info

If you need more information about the paths in a particular working copy, run the ‘svn info’ command. This will display:

  • Path
  • Repository URL
  • Repository Root
  • Repository UUID
  • Current revision number
  • Node Kind
  • Schedule
  • Information on the last change that occurred (author, revision number, date)

svn info

3) SVN Status

This command prints the status of your files and directories in your local working copy:

svn status (working-copy-path)

svn status

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

 

Subversion Tip of the Week

SmartSVN Quickstart

In Apache Subversion, the basic workcycle follows the ‘checkout-edit-update-commit’ format.

In this week’s tip, we get you off to a flying start with SmartSVN, the popular graphical client for Subversion, by covering the entire workcycle in three simple steps.

Step One: Perform a Checkout

1) Open the ‘Project’ menu and select ‘Check Out…’

2) Enter the URL of the repository you wish to checkout. Select ‘Next.’

3) Select the directory to checkout. If you want to checkout a revision other than Head, select the ‘Show Revision’ button and specify a revision number.

4) When you are happy with the information you’ve entered, select ‘Next.’

5) In the subsequent dialog, enter the local directory where you’ll store your working copy. Select the checkout depth, and click ‘Next.’

6) Choose whether to checkout a working copy or export files only. Select ‘Finish.’

7) SmartSVN will perform the checkout. You can now work on the files and folders in your newly-created working copy using SmartSVN.

Step Two: Perform an Update

Before you commit your changes back to the repository, it’s good practice to perform an ‘SVN Update.’ This is made easy with SmartSVN, simply press the ‘update’ button in the toolbar to get started.

In the subsequent dialog, specify which revision you wish to update to (default is the Head) and confirm the update.

Step Three: Perform Your Commit

Perform a commit by selecting the ‘Commit’ button from the toolbar.

Enter an appropriate log message and confirm the commit.

Looking for a cross-platform graphical client for your Subversion project? A free 30 day trial of SmartSVN Professional is available now. Find out more about SmartSVN at www.smartsvn.com

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 Tip of the Week

Apache Subversion: Basic Workcycle

In Apache Subversion, the basic workcycle follows the ‘checkout-edit-update-commit’ format.

A ‘Checkout’ is the process of pulling all the files from your repository onto your local machine, where it becomes known as a ‘working copy.’ You can then work on these files in isolation, before sharing your work with the rest of the team by ‘committing’ back to the repository.

In this week’s tip, we’ll provide a handy introduction to this basic workcycle.

Checkout

To checkout a working copy, run the ‘svn checkout’ command, followed by the URL of your repository and the location where you wish to create the working copy.

In this example, we’re creating a working copy on the desktop, in a file called ‘Repo’:

Tip, if you’re using the free uberSVN platform, you can easily find out your repository’s URL by opening the ‘Repositories’ tab.

You can now edit the files and folders in your working copy.

Update

You may be ready to share your changes with the rest of your team, but it’s good practice to perform an SVN update first. This will pull any changes your colleagues may have already committed, into your working copy, ensuring your changes fit with the most up-to-date version of the project.

To perform an update, run the ‘svn update’ command, followed by the location of your working copy.

svn update (working copy location)

Commit

Let’s assume any changes your team committed are compatible with your changes, and go ahead with the commit. When performing a commit, you should leave a log message and include as much information as possible, as this can be an invaluable source of information if you ever need to revisit this revision. When performing a commit, the log message is entered in the “–m” format (for example, -m “added ReadMe file.”)

The commit itself is performed using the ‘svn commit’ command, followed the log message and the location of the working copy.

svn commit -m “log message” (working copy location)

In this example, we are performing a commit with the log message “added Admin Guide text.”

Need more Subversion know-how? After getting a great response from the Apache Subversion community in 2011, Subversion Live is back for 2012, bringing the Subversion community sessions covering everything from Subversion’s future, to expert-led best practices workshops, as well as the unique opportunity to meet the core Subversion committers. We’re currently running a very special early bird offer: register now using the ‘earlybird’ code to get a 25% discount (note, the early bird offer ends 10th August, so you better be quick!)

Subversion MultiSite Enables Agility For the Distributed Enterprise

The Agile methodology has become a wildly popular approach for software development with close to 50% of development teams using at least some agile techniques based on different surveys. The responsibility of an agile team is to deliver value in the software they are creating and meet the criteria or objectives that determine success for the project and a common set of development “best practices” have arisen that are crossdisciplinary. Adopting these best practices can be especially challenging for collaborating agile teams that are distributed or have distributed members.

The Agile principles state that successive short development cycles, popularly referred to as rapid iterations, be used to develop software quickly in little bits (pun ;)) at a time. Different methodologies have arisen from the Agile principles like Scrum, XP, TDD, Crystal and others which define activities and process for agile teams. The process gets into the specific details for each discipline but agile teams enjoy a great amount of freedom for self organization as well as self definition which as a result teams may borrow one aspect of another methodology to apply to their own agile approach. Popular examples of this are the XP User Story or and the Scrum Backlog.

The common principles mixed together with the common practice of borrowing the best aspects of each discipline has helped popularize a set of software development best practices. These are practices which are good for any software development team but the popularity and nature of agile software development has led these practices to be commonly associated with agile specifically. Here is a list of the more common agile best practices:

  • Rapid Iteration
  • Continuous Integration
  • Parallel Development
  • Frequent Commits
  • Automated Testing
  • Code Review
  • Refactoring

If you are an enterprise considering a large scale adoption of agile software development practices then there are a number of challenges that you may be facing. Scaling Scrum is well documented in Ken Schwabers book “The Enterprise and Scrum” and he has special sections dedicated to the problems of distributed teams, distributed members and the scarce skills problem (eg: one DBA shared by many teams). Ken handles the issues associated with the organization and daily routine for Agile Scrum adopters, but what about the technical challenges especially those associated with the best practices I listed? This is an area where the value added services offered by WANdisco enter the conversation.

Using Subversion Multisite and Apache Subversion will enable teams to fully adopt an Agile practice like Scrum on an enterprise scale, especially where distributed teams or members are concerned. Here is how.

  1. Subversion Multisite instantly synchronizes development changes between locations. This means that distributed teams always work against a local source code repository, without which frequent commits, continuous integration, code reviews and parallel development might not be possible at all or at best will be severely hindered if users are required to connect across the internet to access the source code repository (for read or write activities)
  2. Multisite also supports local clustering option, an enterprise that sets up two or three load balanced Subversion servers will better handle the increased traffic from frequent commits and especially from continuous integration where automated tests and builds are being performed continuously and using up a lot of server resources.
  3. Multisite leads to improved team communication, imagine a tester working in Los Angeles getting the latest build locally almost immediately after a task is committed in New York (again locally). When each site has access to a complete replicated copy of the source code repository many things are possible and the usual downtime related to downloading a new build off a remote server or uploading a set of new changes to a remote server can be entirely eliminated.

An enterprise that is considering or has already adopted agile practices will also want to adopt the software best practices. Given the nature of agile development and rapid iterations adopting these best practices are critical and with Subversion Multisite many of the technical challenges facing distributed teams can be easily solved. There are of course other benefits to Multisite such as built in disaster recovery, guaranteed uptime that will also interest any enterprise and the value offered to Agile teams will be indispensable especially as the Agile usage scales upwards.

Intro to Subversion Access Control 4.1

Big plans are brewing at WANdisco for 2012, and one project that has just been completed, is Subversion Access Control 4.1.

Access Control 4.1 includes a revamped user interface. The new look makes it easier for users to navigate through the security features offered by Access Control and setup new rules and permissions for Subversion repositories and paths.

The ‘Group’ concept has been replaced with “Teams’ and a new feature has been added to allow the designation of “Team Leader” who is then granted some administrator privileges. Specifically, the Team Leader is able to setup user access rules to a pre-defined repository path (or paths).

We are calling this new feature Delegated Admin since it allows granting of some administrator privileges to users. The context of how this feature could be used might be best described in terms of business units for an enterprise corporation. Consider the following scenario.

A company has 100 Apache Subversion users split into 10 teams, each associated with a separate BU, each team has its own Subversion repository. In the past, Access Control admin can go in and setup repository security rules that applies to all 100 users and repositories. With delegated admin the Access Control administration can create 10 new Teams and assign a Team Leader to each one, specifying the Repository that team should have access to. From there, the Team Leader can log into the system, add/remove the users for the team, and setup multiple rules needed to properly manage those Subversion assets.

Effectively what delegated admin does is allow Team Leaders, people in charge of their respective Business Units, to define and configure their own team rules. Access Control supports the concept of nested-teams which is called Sub-Teams (see screenshot) and this would even allow you to further organize teams from larger sections into multiple sub-sections (eg: West Coast Branch –> Plugins Team; West Coast Branch –> Application Team) and designate a team leader at each level to manage users and rules.

The role of the Access Control administrator now is to simply define Team Leaders and the resources which they can direct access over. Once defined the Team Leader can only create rules that affect their resources meaning the West Coast Branch won’t be able to setup access rules for the East Coast Branch’s repositories and vice-versa.

The ability to delegate some administrator functionality to Team Leaders, and in the context of specific Subversion paths and repositories, is a powerful new feature that will empower enterprise organizations and save time and money. Team Leaders are able to set access restrictions based on the need and requirements of their given team or business unit and no longer have to rely on a single administrator to do that for them.