Subversion Blog

Page 2 of 37

Intro to Gerrit – Subversion and Git Live 2014

You may be aware of Gerrit, the web based code review system. Our Director of Product Marketing, Randy Defauw, has a number of good reasons for adopting it as part of your development process:

The most interesting thing about Gerrit is that it facilitates what some call ‘continuous review’. Code review is often seen as a bottleneck in continuous delivery, but it’s also widely recognized as a way to improve quality. Gerrit resolves this conundrum with innovative features like dynamic review branch creation and the incorporation of continuous build into the heart of the review process.

Gerrit is also notable because it is the most enterprise friendly Git code review system, although it has open source roots. It integrates with all standard authentication frameworks, has delegated permission models, and was designed for large deployments.

Randy is Director of Product Marketing for WANdisco’s ALM products. He focuses on understanding in detail how WANdisco’s products help solve real world problems, and has deep background in development tools and processes. Prior to joining WANdisco he worked in product management, marketing, consulting, and development. He has several years of experience applying Subversion and Git workflows to modern development challenges.

If you’d like to hear more about Gerrit, or Git in general, come see us at Subversion and Git Live 2014.

SmartSVN 8.5 Moves from SVNKit to JavaHL

Following on from the release of SmartSVN 8.5, we wanted to give you a bit more detail about the main big change in SmartSVN 8.5, so here’s Branko Čibej, our Director of Subversion, with an explanation:

One of the most significant events during the development of SmartSVN 8.5 was the decision to adopt the JavaHL library in favour of SVNKit, which was used by all previous releases of SmartSVN.

JavaHL is a Java wrapper for Subversion, published by the Apache Subversion project. The most important difference compared to SVNKit is that JavaHL uses the same code base as the Subversion command-line client and tools. This has several benefits for SmartSVN: quicker adoption of new Subversion features; more complete compatibility with Subversion servers, repositories and other clients; built-in support for new working copy formats; and, last but not least, speed — as demonstrated by the phenomenal performance improvements in SmartSVN 8.5, compared to both 8.0 and 7.6.

The decision to adopt JavaHL has also benefited the Subversion community at large: several bug fixes and enhancements in Subversion 1.8.8 and the forthcoming 1.8.9 and 1.9.0 releases are a direct result of the SmartSVN porting effort. We will continue to work closely with the Apache Subversion developers to further improve both JavaHL and Subversion.

Hope that helps explain what’s going on a bit and why we opted to make the change, though it’s worth bearing in mind this is largely an ‘under-the-hood’ change and you won’t notice much difference in the interface. The change will however make future development of SmartSVN much easier.

If you want to see more about the speed improvements there’s a results table in the release blog here.

Cheers all.

SmartSVN 8.5 Available Now

We’re happy to announce the release of SmartSVN 8.5, the graphical Subversion (SVN) client for Mac, Windows and Linux. SmartSVN 8.5 is available for download from our website here.

Along with several bug fixes and enhancements, SmartSVN 8.5 makes the critical move from SVNKit to JavaHL, the same back end as used by the Subversion command line client/server.

Major Improvements

Whilst it may not look different, this release signifies a huge change in that we’ve moved away from SVNkit and SmartSVN now uses JavaHL. This is the same library used by command line Subversion, and has given SmartSVN 8.5 much improved stability and a huge speed boost. Some comparison tables:

Text files
Jpg files
Operation 7.6.3
time (s)
8/8.0.1
time (s)
8.5 (JavaHL)
time (s)
7.6.3
time (s)
8/8.0.1
time (s)
8.5 (JavaHL)
time (s)
Checkout 72.21 78.86 7.34 118.13 120.35 10.92
1st Add 133.60 201.94 37.49 64.19 98.61 15.47
Revert 47.14 75.06 16.89 41.19 77.15 8.85
2nd Add 131.75 186.18 34.64 60.87 101.76 13.81
Commit 314.44 440.23 85.70 167.34 252.85 42.46
Remove 13.86 1146.77 13.76 6.76 553.41 8.70

We’ve also added support for Subversion 1.8.8 and the file:// protocol for local repository access.

For a full list of all improvements, bug fixes and other changes please take a look at the changelog.

Have your feedback included in a future version of SmartSVN

Many issues resolved in this release were raised via our dedicated SmartSVN forum, so if you’ve got an issue or a request for a new feature, head over there and let us know.

You can download SmartSVN 8.5 from our website here.

Haven’t yet started with SmartSVN? Claim your free trial of SmartSVN Professional here.

Subversion 1.9 Underway

Subversion 1.9 is already well underway, following up quickly after last year’s impressive 1.8 release. Although the final set of new features may change, there’s one piece of infrastructure work that’s worth highlighting.

A new tunable to control storage compression levels lets you choose a better balance between repository size and server CPU load. Disabling regular compression and deltification will yield a substantial improvement in throughput when adding, committing, and checking out large files.  You can expect to see more numbers at the next Subversion & Git Live conference, but I will mention that commit speed can increase from 30-40 MB/s to 100 MB/s.

Here are a few other tidbits that may interest you:

  • New tool to list and manage cached credentials

  • The ability to commit to a repository while a pack operation is in progress (Goodbye, long maintenance windows!)

  • Infrastructure work is starting for a new storage layer that will reduce repository size and improve performance.

While you’re waiting for Subversion 1.9, now’s a great time to upgrade to Subversion 1.8. You can enjoy many of the benefits just by upgrading the Subversion binaries on your server.

SmartSVN 8.5 RC2 Released

We’re happy to say we’ve just released SmartSVN 8.5 Release Candidate 2. SmartSVN is the cross-platform graphical client for Apache Subversion.

Major Improvements

Whilst it may not look different, this release signifies a huge change in that we’ve moved away from SVNkit and SmartSVN now uses JavaHL. This is the same library used by command line Subversion, and has given SmartSVN 8.5 RC2 much improved stability and a huge speed boost. Some comparison tables:

 
Text files
Jpg files
Operation 7.6.3
time (s)
8/8.0.1
time (s)
8.5 (JavaHL)
time (s)
7.6.3
time (s)
8/8.0.1
time (s)
8.5 (JavaHL)
time (s)
Checkout 75.27 81.61 26.22 75.64 81.52 27.69
Add 52.77 131.22 67.37 37.38 72.12 22.22
Revert 36.83 60.02 33.74 33.80 69.67 18.08
Commit 195.15 279.49 75.31 116.07 176.88 40.63
Remove 8.75 1176.24 21.38 5.57 595.71 11.58

We’ve also added support for Subversion 1.8.8 and the file:// protocol for local repository access.

For a full list of all improvements, bug fixes and other changes please take a look at the changelog.

Though this is still a release candidate, given the major improvements to performance we strongly recommend that all customers using SmartSVN version 8 or newer upgrade to this latest RC.

Have your feedback included in a future version of SmartSVN

Many issues resolved in this release were raised via our dedicated SmartSVN forum, so if you’ve got an issue or a request for a new feature, head over there and let us know.

You can download Release Candidate 2 for SmartSVN 8.5 from our early access page.

Haven’t yet started with SmartSVN? Claim your free trial of SmartSVN Professional here.

SCM is for everyone

A recent Forrester survey revealed some startling information about the adoption of SCM tools in the enterprise: 21% of the respondents are not using any SCM, and 17% are using tools that are a couple generations out of date.

That information caught me off guard, but then again I work in the industry and probably tend to focus more on the up-and-coming than the tried-and-true. As I’ve been mulling this over, I’ve started to recall my own very first exposure to SCM.

The year was 1996, and I was an undergraduate research assistant working on an autonomous vehicle project. (Note to my children: yes, I do *really exciting and super cool* things at work.) I was on a team of five electrical engineers that wrote a lot of C code for image processing and vehicle control. Like a lot of ‘software developers’, however, we were domain problem solvers first and coders second.

 

For a while we did backups of our code on network drives and tapes. Then we heard about something shocking: a tool called Visual Source Safe (VSS) that would easily store every version of our code, let us see how it changed, and revert changes easily. We could even make a branch as well as work on bug fixes and new experiments at the same time! (Of course we were programming half on Linux so we couldn’t use VSS for everything, and therefore had to learn the unpleasantness of CVS.)

Back to the point: normally when someone asks me about the importance of SCM, I start thinking about the mainline model and how SCM is the one of the foundations of continuous delivery. To take a step back, anyone who writes software, from assembly motor control code to Hadoop plumbing, needs to use SCM for the same three reasons I needed it in 1996:

  • Backups. Code is valuable.

  • History. Being human, you may make mistakes and need to discover/roll back those mistakes.

  • Branching. You sometimes need to work on bugs and new stuff at the same time.

Luckily, you’ve got better choices now than I did in 1996. Subversion and Git are two free, powerful, and mature SCM choices available on every platform. Both are fairly friendly to the newcomer particularly if you pick a GUI, and most applications that work in any way with source code will integrate with them.

So no more excuses – head over to our website for binaries, community forums, and quick reference cards and tutorials.

LDAP Authentication in SVN 1.8.8

Following a thread in our Subversion forums, we’ve found that some people are having problems with LDAP after upgrading or installing version 1.8.8. So far this has only been reported on the Redhat and CentOS builds.

These builds use an updated apr-util package which no longer offers support for ldap – this has been moved to a separate package, apr-util-ldap, which wasn’t included.

We’ve now updated the dependencies in that package to include the necessary missing package, apr-util-ldap. If you’re getting this error, just re-run yum install subversion and the missing files will be installed for you.

Many thanks to Philip, one of our Subversion committers, for highlighting the issue so that we could sort it 🙂

America Invents Act and the Prior Use Defense

Proving Your Right to Continued Use with Global Repository Management

One of the significant changes in the America Invents Act (AIA) is the expanded scope of the ‘prior use’ defense. Before the AIA, the prior use defense only applied to business method patents, but it is now an effective and increasingly important defense in patent disputes centered on any process, machine, or manufacture – if you can prove a valid prior use a year before the filing date or public disclosure of the claim in question.

Why is prior use so important now? For starters, the pace of patent litigation is on a sharp upward trajectory. Between 2008 and 2012 the number of patent cases commenced rose from under 3,000 a year to over 5,000 a year. Any effective defense is worth considering in this environment.

Also bear in mind that the AIA changed from a first-to-invent scheme to first-to-file. If a patent troll files the paperwork first to claim an invention, you could be at risk. Establishing with clear and convincing evidence that you were using the invention over a year before the filing is a very strong point in your favor.

The best evidence of prior use of software inventions is the audit trail provided by your SCM repository. By its nature an SCM repository tracks the birth of a software implementation: the combination of source code, libraries, build scripts, and deployment processes that shows how and when you started using an invention.

But there’s one fly in the ointment – the use of ‘skunk works’ repositories. Some development teams using Git like to stand up informal repositories to work on new ideas or pet projects, only moving the project into the ‘official’ repository when it reaches some stability milestone.

That’s clearly a problem. As we’ve seen from the time frames in the AIA, every day counts when you’re establishing a prior use defense. If you lose the first three months of prototype history because the ‘skunk works’ repository was lost, you may slip past the one year limit for prior use.

Before you try to enforce a policy against these ‘skunk works’ repositories, keep in mind why Git development teams might use them:

  • They’re working at a remote office and the network latency is making their Git operations painfully slow.

  • The official Git repositories are slow due to too much load on the system from a large user base and build automation.

  • The process of requesting an official repository and adding it to the enterprise backup and security schemes is too time consuming.

The solution is a fast and stable enterprise Git service that is easily accessible for any development team. In other words, make it easier for developers to use your secure and highly available Git repositories and they won’t be tempted to set up their own infrastructure.

Git MultiSite provides the enterprise Git solution that fits the bill. With Git MultiSite’s patented replication technology, every development team gets a local Git repository with fast LAN access. Every Git server in the deployment is a fully replicated and writable peer. Slow Git operations are a thing of the past, with most operations being local and commits (pushes) being coordinated very efficiently with other nodes in the deployment. Plus, Git MultiSite’s automated failover and self-healing capabilities mean zero down time.

Git MultiSite and Git Clustering also provide a very scalable solution. Additional Git servers can be added at any time to handle increased load, giving you more confidence to spin up new Git repositories for every pet project that might turn into the next big thing. These new repositories can be deployed at the click of a button in the administration console.

Finally, Git Access Control makes sure that your security policies and permissions are applied consistently at every site, on every server.

Git MultiSite removes the performance and security concerns that normally make you hesitate about providing ‘self-service’ SCM infrastructure, eliminating the need for ‘skunk works’ repositories.

The AIA makes it more important than ever to keep track of every software recipe in your organization. Let Git MultiSite provide the infrastructure you need to protect all of your intellectual property.

 

Rebasing in Subversion

One of Git’s most popular features is the rebase command. Rebasing has several uses, but one of the most interesting is the ability to ‘merge without merging’. In other words, you can take a set of commits from a branch and reapply them to the same branch after adjusting the branch pointer. A couple of pictures will help to illustrate the concept as we try to keep a topic branch up to date with the latest work from master.

In this picture we start with a master branch, then make a topic branch and record a commit there. Next we switch back to master and record another commit. Then we merge master to topic to pick up the latest trunk work, and end up with a merge commit.

Rebasing lets us take a different approach.  

We start out the same way, but instead of merging master to topic, we rebase topic to master. That takes our local commit (t-1) and reapplies an equivalent patch after moving the topic branch to the head of master. The net effect is that it looks like topic was created from the current head of master. This is a really useful way to keep topic up to date with master without recording a bunch of merge commits.

It’s not possible to do this directly in Subversion, but there is a recipe that gets you close. First let’s look at the normal situation in Subversion when I work on a topic branch and do a refresh merge from trunk.

The revision graph (from SmartSVN) shows what you’d expect, although note that Subversion revision graphs don’t show the merge arrows.

Now let’s look at how to get to this point instead:

I can’t change my branch pointer in Subversion like I can in Git, but I can create a new branch (I’ll call it feature_prime) that starts from the new tip of master and then apply any patches from the original feature branch. At this point I can throw away the original feature branch and continue working on feature_prime. It’s not an ideal solution, but may still be useful in some cases.

How did I get there?  Here’s the recipe, starting after the m-2 commit on master:

# make feature_prime branch
svn copy ^/master ^/feature_prime -m "mkbranch"
svn up
cd feature_prime

# calculate diffs between feature and master
svn mergeinfo --show-revs eligible ^/feature ^/master

# for each rev found, run a cherry pick merge into feature_prime
svn merge ^/feature -c 8 --ignore-ancestry
svn commit -m "rb-8”

Essentially we find the deltas between feature and master, then run an ignore-ancestry merge to get them into the new branch. That type of merge ignores the normal merge history and just calculates diffs.

In my next post about rebasing in Subversion I’ll talk about the more general case of rebasing in Git, which turns out to be easier to emulate in Subversion.

 

Apache Announces Subversion 1.7.16

On the heels of Subversion 1.8.8, I’m pleased to announce the release of 1.7.16 on behalf of the Apache Subversion project. Along with the official Apache Software Foundation source releases, our own fully tested and certified binaries are available from our website.

1.7.16 is a bugfix and security fix releases and does not include major new features. 1.7.16 includes the following changes:

  • A security fix that prevents Apache httpd from crashing when SVNListParentPath is turned on and certain requests are received. Further details on the issue can be found in the advisory the Apache Subversion project has published.
  • Reduced memory usage in both server implementations during checkout and export operations.
  • Fixed an issue that caused executing a copy of a relocated path to break the working copy.
  • Resolve a number of regressions in diff that we introduced in 1.7.14. Most notably, requesting a diff against a specified revision and a working copy file that had a svn:mime-type property would fail.

For a complete list of new features and fixes, visit the Apache changelogs for Subversion 1.7.

You can download our fully tested, certified binaries for Subversion 1.7.16 free here.

WANdisco’s binaries are a complete, fully-tested version of Subversion based on the most recent stable release, including the latest fixes, and undergo the same rigorous quality assurance process that WANdisco uses for its enterprise products that support the world’s largest Subversion implementations.