sherpa's WANdisco Blog

Subversion Tip of the Week

Published by sherpa on May 14, 2012 in General, Subversion, uberSVN and WANdisco. 0 Comments Tags: jenkins, plugin, tip of the week, uberSVN, WANdisco, wdfront.

Extending Jenkins and uberSVN

uberSVN makes Jenkins easy to install, but the standard installation contains only the bare minimum needed by the average developer. At some point, you will want to extend your uberSVN and Jenkins installation with additional plugins. Thankfully, this is made easy in uberSVN.

1) Start by clicking on the ‘Jenkins’ tab in uberSVN. From here, select the ‘Manage Jenkins’ option followed by the ‘Manage Plugins’ option.

2) Select the ‘Available’ tab and check the tick boxes of all the plugins you wish to install.

3) Once you have selected all the plugins you wish to install, scroll to the bottom of the page and hit ‘Install.’

4) The plugin will now be downloaded. Note that Jenkins will need to be restarted for these changes to take effect.

Our Support Engineers are the Sherpas of Source Control Management! Just as traditional Sherpas use their deep knowledge of local terrain to assist mountain climbers in reaching the highest peaks and avoiding pitfalls along the way, WANdisco’s Subversion Sherpas use their extensive experience to guide customers away from problems and enable them to get the most out of Subversion. Our ‘Team Sherpa’ consists of highly skilled support engineers and core Subversion developers who have been working on the Subversion project since it began, and are also uniquely positioned to help you migrate to the latest and greatest releases of SVN. You can hire one of our Subversion Sherpas today, by visiting http://www.wandisco.com/subversion/support

Subversion Tip of the Week

Published by sherpa on April 30, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: admin, apache, best practices, ci, jenkins, Open Source, OSS, Subversion, SVN, tip of the week, WANdisco, wdfront.

Admin Best Practices

Apache Subversion users have the freedom to structure their repository according to a project’s particular needs, but if you don’t implement a logical project layout, you’re running the risk of creating an administrative nightmare. Here are some general rules worth bearing in mind when creating a new Subversion repository, to ensure all that freedom doesn’t lead to complications.

The code in the trunk should be stable – all experimental development should be confined to separate branches.
Consider CI and automated regression testing – these can help ensure there is no regression in the all-important trunk. uberSVN users can download the popular Jenkins open source CI server for free from inside their installation.

Make snapshots of your project – tags should be used to make snapshots of your project at certain points during the development process (e.g tagging a snapshot as ‘Release 1.0.’) It is also good practice to make snapshots of your project before implementing major new features. This makes it easier to roll back and effectively ‘undo’ the new feature, if required.
Take care when making structural changes – structural changes should always be performed on the trunk, when there are no branches waiting to be merged. This can help development teams avoid serious and time-consuming conflicts.
Use changelists – if you are working on several different issues simultaneously, there is a risk of losing track of which files relate to which issue. In these situations, it can be helpful to organize your files into ‘Changelists.’ Changelists can be created either from the commit dialog, or the ‘Check for modifications’ dialog. In this example, we’ll look at creating a changelist from the commit dialog:

1) Highlight the files you wish to place into a changelist, right-click and select ‘Move to changelist.’ In this example, we’ll be creating a new changelist.

2) Enter a name for your changelist and select ‘Ok.’

3) Your modified files will now be automatically organized according to the new changelist. This allows you to see at-a-glance, which modifications have been made for each task, and to commit these changes separately.

Subversion Tip of the Week

Published by sherpa on April 23, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: merge, Open Source, OSS, Subversion, SVN, tip of the week, tortoisesvn, WANdisco, wdfront.

Merging a Range of Revisions with TortoiseSVN

TortoiseSVN’s ‘Merge’ functionality is essential for projects where separate lines of development are maintained. At some point, the changes will need to be merged from one branch, into the trunk (or vice versa!) This method is useful when you have made one, or more, revisions to a branch (or trunk) and you need to port these changes to a different branch.

1) Select the branch where you wish to perform your merge. Right-click and select the ‘Merge’ option from the TortoiseSVN sub-menu.

2) Select ‘Merge a range of revisions’ and click ‘Next.’

3) Select the URL containing the changes you wish to port to your working copy, and the revision range to merge. For more information on the different revisions you can choose from, click ‘Show Log.’

4) This dialog displays all the recent changes and log comments. To merge the changes from a particular revision, simply select that revision. To select a range of revisions, use the Shift-modifier. When you are happy with your selection, click ‘Ok.’

5) The range of revisions you are about to merge are automatically added to the Merge dialog. Click ‘Next.’

6) This page lets you specify some advanced options, although in most situations you can use the default settings. Click ‘Merge.’

7) You will see the following message, informing you that your merge has been successful.

TIP: Merging always takes place within a working copy, and it is good practice to perform a merge into an unmodified working copy. If you have made some changes to your working copy, you should commit these first – merging can become a complicated process, and if a merge doesn’t go quite as expected, the quick-fix ‘Revert’ command will discard all changes, including any you neglected to commit before starting the merge.

Subversion Tip of the Week

Published by sherpa on April 16, 2012 in General, Subversion, Tip of the Week and WANdisco. 1 Comment Tags: apache, apache software foundation, asf, log messages, Open Source, OSS, Subversion, SVN, tortoisesvn, wanddisco, wdfront, windows.

Editing Log Messages

At some point, you may wish to add, delete, or alter the information contained within the log messages from previous revisions. This is made easy with TortoiseSVN.

Tip: The ability to edit log messages is disabled by default. To enable it, modify the pre-revprop-change hook, which can be found in the “hooks” folder of your repository.

1) To get started, select the ‘Show log’ option from the TortoiseSVN menu.

2) In the ‘Log messages’ dialog, right-click on the desired revision and select ‘Edit log message.’

3) You can now edit the revision’s log message. Once you are happy with the changes, click ‘Ok’ to save them.

Subversion Tip of the Week

Published by sherpa on April 10, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: apache, asf, Open Source, OSS, Subversion, SVN, tip of the week, WANdisco, wdfront.

Solving the “Working Copy is out of date” Error

When attempting to commit your changes back to the Subversion repository, you may see a “working copy is out of date” error similar to the one below.

There are three main causes of a “working copy is out of date” error:

1) If your commit was interrupted in the time between the new vision being added to the server, and the client performing its post-commit admin tasks, leftover debris from this failed commit could be causing the error. The first step, is to determine whether the changes actually reached the server or not. This is achieved with the ‘svn log’ command:

svn log (PATH)

If ‘svn log’ reveals that the commit actually succeeded, you need to bring your working copy in line with the repository. In this instance, you can use ‘svn revert’ to revert the local changes:

svn revert (PATH)

Now, run an ‘svn update’ to get your changes back from the server.

2) Another possible cause, is mixed revisions. The SVN commit command only increases the revision number for the files it touches, which can lead to different revision numbers within the same repository. There are certain operations that will fail if the repository has a more recent version of the node. This can be fixed by running ‘svn update’ in the working copy.

3) Finally, your working copy could actually be out of date! If someone has committed their own changes to the repository since you checked out, or last updated, your working copy, an ‘svn update’ is required before you can commit your changes.

Subversion Tip of the Week

Published by sherpa on April 2, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: apache, asf, client, Open Source, OSS, Subversion, SVN, tip of the week, WANdisco, wdfront, windows.

TortoiseSVN Quickstart

TortoiseSVN is a popular Windows client for Apache Subversion, that makes version control easy! This week, we will cover all the basic TortoiseSVN operations in six easy steps.

1) The first step, is to checkout a working copy. Open the location on your hard drive where you wish to create your working copy, right-click and select ‘SVN Checkout.’

2) In the Checkout dialog, enter the URL of your repository and click ‘Ok.’

3) TortoiseSVN will now checkout a working copy. Click ‘Ok.’

4) Make some changes to your working copy. Note that if these changes include creating new files, you must ‘Add’ them to TortoiseSVN before they are placed under version control.

5) Once you have finished making your changes, click ‘SVN Commit…’ to commit your changes back to the repository.

6) Another essential function for your TortoiseSVN development, is ‘SVN Update.’ This command pulls updates from the repository into your working copy, reducing the chances of encountering merge conflicts when you perform your own commits. This is made easy with TortoiseSVN, simply select the ‘SVN Update’ option from the Windows context menu.

And that’s it! You’re now ready to continue making changes to your working copy, and committing them back to the repository, while running regular ‘SVN Updates’ to ensure all the latest repository changes are pulled into your working copy.

Need some extra help with your TortoiseSVN installation? We provide professional support for TortoiseSVN

Subversion Tip of the Week

Published by sherpa on March 26, 2012 in General, Subversion, Tip of the Week and WANdisco. 2 Comments Tags: apache, asf, Open Source, OSS, Subversion, SVN, tip of the week, WANdisco, wdfront.

How to Checkout a Single File

While Apache Subversion does not allow you to checkout a single file as such, if you checkout a copy of your entire repository, there is a way to export a single file from that working copy (note, this exported file will not be under version control.) Exporting a single file in this way, makes use of the ‘svn export’ command.

1) To get started, checkout a copy of your repository, decide which file you wish to export and then open the terminal window. To export a particular file from your working copy, to a particular location, use the following command:

svn export PATH1 PATH2

(PATH1 is the location of the file you wish to export, and PATH2 is the location where it will be exported to.)

In this example, the command will look like this:

2) Following a successful export, you will see an “Export complete” message.

3) You will notice an unversioned copy of the file has appeared in the specified location. In this example, this is on the desktop.

Need some extra help with your Subversion implementation? We offer professional support for Apache Subversion, featuring guaranteed response times and 24-by-7 worldwide coverage.

Subversion MultiSite Enables Agility For the Distributed Enterprise

Published by sherpa on February 22, 2012 in Sherpa's, Subversion and WANdisco. 0 Comments Tags: Agile, agility, apache, asf, enterprise, multisite, sherpa, Subversion, SVN, WANdisco, wdfront.

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.

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)
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.
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

Published by sherpa on February 17, 2012 in General, Sherpa's, Subversion and WANdisco. 0 Comments Tags: access control, access control 4.1, admin, apache, enterprise, multisite, sherpa, Subversion, SVN, WANdisco, wdfront.

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.

March of the uber

Published by sherpa on November 28, 2011 in uberSVN and WANdisco. 0 Comments Tags: Agile, ldap, sheffield, social coding, subversion 1.7, uberapps, uberSVN, WANdisco, Waterfall.

So, we thought it would be good to give you a ‘broad stroke’ update on what’s going on in the world of uberSVN. Firstly, you’ll probably have noticed that another update recently appeared; a modest interim fix that sorts out some niggles encountered by Subversion 1.7’s early adopters. If you didn’t catch the update, here’s what changed:

uberSVN – Release 11.11

What’s New

[Portal] It’s no longer possible to browse to cached screens without re-authorization. (ESVNB-2157)

[Portal] We’ve cleaned up the layout of the uberSVN login screen. (ESVNB-2265)

[uberAPPS] We’ve changed our back-end server to use the C3P0 connection pooling library to improve the handling of long running connections to the database. (ESVNB-2267)

What’s Fixed

[svnSWITCH] We’ve fixed an issue where running with Subversion 1.7 stopped the repository browser from working. Also fixed is the problem with repository browsing that occurred if you switched to Subversion 1.7 when using SSL. (ESVNB-2468) (ESVNB-2473)

[svnSWITCH] Windows XP users are now able use the SVNswitch tool. (ESVNB-2471)

[svnSWITCH] Activating Subversion 1.7 no longer stops commit activity from being reported on the dashboard or repository activity stream. (ESVNB-2472)

The bigger picture

This is the 7th update in the 7 months since our first release – from that you can probably work out the release cycle that we’re aiming for, and so far hitting. This release tempo should also tell you that there’s been no slow-down here at WANdisco’s Sheffield-based software forge – indeed, if cities had middle names, Sheffield’s might be ‘Industrious’, and it’s hard for a developer of software tools to not be inspired by a city that unexpectedly became the world’s supplier of industrial tools.

If that allusion to Sheffield’s heritage seems like big talk from a small “upstart”, maybe it’s because we know we’re on to something and we’ve got the potential to change the game, if we can keep on course, and keep on delivering regular improvements. To this end we’re very happy with the results we’ve got from an Agile approach. Keeping your releases bite-sized but regular forces you to keep the focus on stuff that works rather than trying to build Rome in a day. Of course, in an office with a giant slide, who needs to ride the waterfall?

Now we’d concede that this might give the impression that the big changes are never coming, in fact you can be sure that they are. Our Suggestion Website has given us an invaluable insight into what many of you like about uberSVN, but more importantly it tells us what holes we need to fill. Full LDAP integration, Defect tracker, anyone? We are hard at work on plugging both into uberSVN, as well as a few other things-that-you-want. Of course, there are lots of features and capabilities that fall outside the scope of what we can build ourselves, we’ll still be able to deliver these through uberAPPS, which will soon benefit from another round of enhancements, and some cool new APPS for you to buy

It’s your turn

For us, uberSVN’s social coding element is important because software development, at its best, should be a conversation – sometimes, an argument. So we’ll ask again, keep asking us for stuff, most definitely keep telling us what we’re doing wrong. Most of all, keep talking.

Not given uberSVN a try? It’s here, it’s FREE, and so easy to install your kids could do it - in fact, ours did. http://www.ubersvn.com/

sherpa's WANdisco Blog

Subversion Tip of the Week

Subversion Tip of the Week

Subversion Tip of the Week

Subversion Tip of the Week

Subversion Tip of the Week

Subversion Tip of the Week

Subversion Tip of the Week

Subversion MultiSite Enables Agility For the Distributed Enterprise

Intro to Subversion Access Control 4.1

Search

Authors

Blog

WANdisco

Categories

Follow us on twitter

WANdisco Products