Major New Subversion Edge Release Available

Posted by Mark Phippard on April 30, 2012

Subversion Edge 3.0 was released over the weekend. This is a significant new release with many new features, a brand new user interface and a number of refinements to the user interface and features.

Let me start with the brand new user interface. You can see the new logo in the top corner of this post, and you can see a new screenshot gallery here which covers a lot of the UI. The new UI is more than a fresh coat of paint, we took the new branding as an opportunity to overhaul the UI itself. The UI is now built on a modern HTML5/CSS3/JavaScript foundation with a responsive design that responds to CSS3 media queries. That means the UI will adjust itself based on the size of your desktop browser, smartphone or tablet. We also updated the navigation by reducing the number of top-level elements and moving some of the existing elements beneath others. This is the first major refactoring of the UI. As we have grown in features release after release, it was time to simplify the navigation and group some of these items with others.

As part of updating the UI to a modern framework, we also consolidated all of our JavaScript usage to the jQuery library. This brings smaller page sizes since all of our JavaScript uses the same library and also brings consistency in areas like modal dialogs where we now have a consistent way to use these across the application. Using jQuery also allowed us to update our display of data in tables to use the excellent jQuery Datatables library. This brings features like fast paging and filtering of table data as well as allowing you to dynamically control the number of table elements you want to see.

I am really excited about the new user interface and I invite you to give this new version a try and let us know what you think.

The most significant new feature we are announcing in this release is the support for backup to the cloud. This exciting new feature is part of the hybrid-cloud strategy that CollabNet is announcing today. With this feature you can connect your Subversion Edge server to CloudForge; enabling you to synchronize your repositories to the cloud and safeguard your data in our data centers. Getting started is a very simple process where you just “set it and forget it”. Pick your repositories, pick your schedule and Subversion Edge does the rest. Of course, restoring repositories from the cloud is just as simple. Once your Subversion Edge server is connected to your CloudForge account, you can create a new repository and browse the cloud to choose an existing repository and have the data pulled down from the cloud to populate the local repository.

Subversion Edge also now allows you to define multiple backup schedules for a repository. This means you could define one schedule to do something like a daily hotcopy backup of your repositories to your local disk or network, and another schedule to do an hourly backup to the cloud. Cloud backups only need to synchronize the changes since it last ran, so it is lightweight and easy to run these backups frequently. We have also made changes to improve the scalability of the local backup jobs such as reducing the number of jobs that run at once and adding intelligence to the jobs so that they are skipped when the repository has not changed since the last backup.

The new user interface and cloud backup are just the big new features, there have been a lot of other improvements made in this release. You can see more information in the wiki here.

Download Subversion Edge 3.0 today and please remember to provide us feedback in our forums or your own blog.

Finally, do not forget to signup to view the exciting announcements that CollabNet is making today. There are two scheduled viewings for these announcements and they will be available for replay later in the week as well.

Category Categories: Cloud Services, Subversion Server, Subversion in the Enterprise | View Comments

Subversion Server Automation

Posted by Mark Phippard on March 8, 2012

Subversion Edge 2.3.0 was released last week with a number of new features. One of those new features is that we are continuing to expose more and more of Subversion Edge via REST API. The documentation for the API is available in the Subversion Edge wiki.

Subversion itself has always had a very rich API for working with your repository data, but the actual configuration and management of a Subversion server resides outside the Subversion software itself. That is where Subversion Edge comes in to play. Subversion Edge is a packaging to the Apache httpd, Apache Subversion and ViewVC open-source products. All fully tested and designed to work together. Subversion Edge also includes a custom web console for configuring and managing your server. This console is what gives you the “Edge” when it comes to managing your server and it is also where the REST API lives. Using this API you can do things like get a list of all repositories, you can create a repository, you can work with the hook scripts for a repository, you can create users etc. Here are some examples for how the API can be useful.

CollabNet Desktop

CollabNet currently offers four distinct “Desktops” (Eclipse, Visual Studio, Windows and Outlook). These desktops deliver our custom clients for TeamForge, as well as Subversion, in a native desktop client. The latest version of the CollabNet Desktops have been enhanced to support Subversion Edge servers via the new REST API. Using the API, a user can just specify the URL of their Subversion Edge server, along with valid credentials, and the Desktop client can then use the REST API to retrieve a list of all of available repositories on that server. If you only have a single repository, this is not that big of a deal, but most of us work with many repositories. Now you do not have to enter all of those URL’s into your Subversion clients in order to browse and checkout code. In addition, when new repositories are created they will automatically show up in your list and be available immediately.

Automation

I was recently doing some testing of the Subversion Edge web UI to see how it worked with large amounts of data, such as thousands of users and repositories. I wanted to have data that looked real world so I did not want to name my repositories with names like repos-1234. Using some screen scraping, I connected to tigris.org and retrieved the names of all of the public projects hosted on that site. This served as a good set of real world data for my repository names. I then just had to write a simple script that read through this list of names and called the Subversion Edge REST API to create those repositories, and I did something similar to create my users. By using the REST API, I was able to easily change my script to target different servers running on different operating systems by just changing the URL in the API call. In a couple minutes I had thousands of repositories and users created on my server and could move on with my testing.

While, it is unlikely that you would want to create thousands of repositories and users the way I did, you still might have internal business systems that you want to integrate with Subversion. For example maybe you have an internal process you follow to request a new repository or to start a new project. When the request is approved, you could now enhance these internal processes to call the REST API to create the repository. Using the repository templates feature in Subversion Edge when creating your repository or the REST API for hook scripts after you create the repository, you can make sure the new repository has all of your corporate standard hooks in place as well.

Integrations

Integrations are just a flavor of automation, but here is another real world example for how the REST API could be used. About a year or so ago I was having a brainstorming session with Kohsuke Kawaguchi of Hudson/Jenkins fame. We were talking about how we could improve the experience of using Jenkins and Subversion together. We already had one piece in place at that time, namely when we designed Subversion Edge we included a Discovery API so that it would be possible to automatically discover Subversion Edge on your LAN. Kohsuke had already been doing something similar with Jenkins, but he liked the way we approached it and wound up adding a similar implementation in Jenkins. So the Discovery API is step one (keep in mind this is all still “vision” at this point). What we imagined was that you already have Subversion setup and you are adding a Jenkins server on your LAN for Continuous Integration. Jenkins could have a plugin for Subversion Edge that auto-discovers your server and then calls an API to get a list of repositories. It could then use this information to assist you in setting up Jenkins build jobs for the projects in those repositories. Finally, because the Subversion Edge REST API also allows you to configure the hooks for a repository, this theoretical Jenkins plugin could also assist you in installing a post-commit hook to trigger your Jenkins builds. This is a more efficient way to trigger builds than polling the repository and also allows your builds to be started faster.

At this point, I do not know if a plugin like this will be created or not, but it should give an idea as to the possibilities that the Subversion Edge REST API now provides. As always, I invite you to come to our open discussion forums to ask questions and exchange ideas. Our goal is to have complete coverage for the entire Subversion Edge web UI available via API. We have been prioritizing around the areas where we think people are most likely to want an API. There is still a little more work to do to have complete coverage via API but we are probably more than two-thirds the way there and think we have likely covered all of the most common use-cases already. Feel free to request additional API or features if you have ideas that are not currently covered or in the plan.

Subversion Edge is FREE and Open-Source. Download it from CollabNet.

Category Categories: Administration, Desktops, Subversion Client, Subversion Server, Subversion in the Enterprise | View Comments

#subversiontags

Posted by Bob Jenkins on December 27, 2011

I have intended for a long, long time now to write a blog post about one of my favorite soapbox topics of configuration management – tagging. It can’t be a hard topic to at least understand the principle given we apply tags to Flickr, hashtags to Twitter, and tags to Facebook. The idea is to apply a piece of metadata to some type of content in each of those tools. That’s what we’re talking about with Subversion with the key being that the metadata is applied to a revision of the folders and files that you’ve put under version control. The purpose isn’t that much different in many ways from tagging in those other tools. You want to draw attention to that revision by providing meaning to the set of folders and files that makes that set important to others, or important over the passage of time.

At best, most projects apply a tag to the revision they approve for deployment into production. That means that the casual user or the new employee months or years later can see on-going development through the individual commits and associated changesets, but it appears as though one day the project team was developing as usual and then the next they suddenly felt the code was worthy of being put into production. Now that’s not usually what happens (one can never say never in some organizations) as instead the project team has a logical and often multi-step process through which to move a revision of code before it is deemed production worthy. Without tags, that information is lost and when someone asks about the process and where it might be improved, they are left with harvesting human recollections that are inherently flawed. A negative event is much like a criticism in that it carries more weight than its opposite. I’ve heard it said that it takes seven compliments to overcome one criticism. I don’t if that’s the right ratio, but it is obvious that it isn’t one to one. If we want to be able to talk accurately about what has gone on historically, we need to have it recorded in a way that keeps it correct and unchangeable.

The value of knowing what a particular engineer did on a particular day at a particular point in time is of quickly decreasing interest over time. The value of knowing what happened in our process of moving developed code to production code is likely to become more value with the passing of time. Oftentimes we just haven’t been asked the questions that require us having that information available yet, so we can’t appreciate its value. We’ve also found that tagging, labeling, or whatever a previous tool did to track this data becomes a drag on performance and scalability over time. We might appreciate some value in having this data tracked, but the trade-off for performance and scalability didn’t make it worth the effort.

Subversion tackles the issue of tagging in the exact same manner as it does branching, but obviously the use of the result is quite different for tagging than it is for branching. The process of creating a tag is consistently quick and with low overhead no matter how few or how many folders and files we’re using. In most cases, we’re talking about capturing two small pieces of data to define our tag – a pointer to the folder at the top of the structure we want tagged, and a global revision number indicating the point in time we want captured. The time and space doesn’t change if the structure contains five folders and a hundred files or if it contains 500 folders and 100,000 files. That means there is no downside to using this functionality to capture the various stages of our “promotion” process, but there is certainly a lot of potential upside. Think about how you would answer the following questions accurately without this data:

How many times was there a handoff from development to the release engineer before a successful test candidate could be built?
How many times did we go through phase M before we were successful and able to move on to phase N?
How much time did we spend in phase M?
Where do we spend the most time in our “promotion” model on average?
How much time does it take for us to get a release out once we’ve started down the “promotion” process?
What files are doing the most thrashing through the “promotion” process?
Who’s consistently responsible for the code issues that cause us to spend time fixing bugs and producing a new test candidate?

For many organizations applying these extra tags is a new part of their processes, but with a little time spent understanding the low cost and high value should make it obvious to add tagging. Even if your tags are more complex than the simple ones discussed above, you would be hard pressed to make a case that the potential value doesn’t significantly outweigh any cost. In short tagging is a #nobrainer.

Category Categories: Subversion Client | View Comments

Subversion Edge 2.2 Released

Posted by Mark Phippard on December 22, 2011

Subversion Edge 2.2 was released this week and brings some exciting new features that our users have been asking for. A general changelog for the release can be found in the wiki. Here are some of the highlights:

Subversion 1.7.2

The Apache Subversion binaries have been updated to the latest release. Subversion 1.7.2 is a bug fix release, the changelog can be found here.

Repository Templates

Prior to this release when creating a new repository your choices were to create an empty repository or to initialize it with the standard trunk/branches/tags structure. A number of users requested the ability to initialize repositories with the standard folder structure that they use in their organization, and other users have asked for the ability to install their standard hook scripts. This release introduces the concept of repository templates which provides both of these features. A repository template can either be a standard Subversion dump file or a zipped copy of a Subversion repository. In either case, the repository can contain whatever content you want and in the case of a zipped repository the template can also include hook scripts.

With this feature you could now disable our templates and replace them with your own that include things like your standard hook scripts and/or the default repository structure that you want. Technically, the template repository can include as much content as you desire, so if you have some standard document or project templates that content can also be included in the repository template.

New Create Repository UI

To go with the previous feature, and to add another one, we have revamped the Create Repository UI. When creating a repository you now have the option of initializing the repository from a template OR from a backup. This works in conjunction with the backup feature we added in the 2.1.0 release by providing a UI to restore any of those backups as part of creating your repository.

REST API – CollabNet Desktop Support

We are in the process of exposing the Subversion Edge administration capabilities via REST API. This release brings the initial release of some of that API. For this release, we focused on the API needed to address the user stories for our CollabNet Desktops. Prior to this release, the desktops only supported Subversion Edge via their capability of working with any Subversion repository. With this release, the desktops now have first class support for Subversion Edge. You can add a Subversion Edge “site” in the desktop by providing the URL and credentials for your Subversion Edge console. The desktop can then use the new REST API to retrieve the list of repositories available and make then instantly accessible in your client. If you work with multiple Subversion repositories this saves you from having to manage connections to each repository. Just connect your client to Subversion Edge and any repositories are instantly available in your client.

The Eclipse Desktop also has support for the Subversion Edge Discovery API. If your client is located on the same LAN segment as the Subversion Edge console you can click a Browse button and have your Subversion Edge server(s) discovered automatically. You still need to provide valid credentials to access the console, but this makes it easy to find it and add the correct URL.

Proxy Server Support

Many users install Subversion Edge on servers that are behind a corporate proxy. When Subversion Edge needs access to the Internet, such as to check for updates or to act as a replica for TeamForge, the proxy server needs to be configurable. Prior to this release you had to configure proxies manually by editing environment variables and configuration files. We have now pulled this into the Subversion Edge UI so you can easily configure your proxy server from the web interface.

This is our 15th release of Subversion Edge since introducing it in the summer of 2010 and there will be more releases to come in the next year. On behalf of the Subversion Edge team I want to thank you for your tremendous support for this product. Happy Holidays! We will see you next year!

Category Categories: Administration, Application Lifecycle Management (ALM), Open Source Software Development, Subversion Client, Subversion Server, Subversion in the Enterprise | View Comments

Subversion 1.7 Q & A, part 4

Posted by C. Michael Pilato on December 2, 2011

So… have you installed Subversion 1.7 yet? Are you enjoying the performance increases it brings? Is WC-NG your new best friend, or are you hanging posters around your home town which read: “MISSING: .svn folders. Last seen hanging around Subversion 1.6. REWARD OFFERED!!”?

Subversion 1.7 has been available for seven weeks now, and has already seen one subsequent patch release, with a second one (1.7.2) expected to be released today or tomorrow. Many of you have embraced this new version of Subversion; others have not. If you haven’t, and you aren’t quite sure what I’m talking about or don’t see the humor in my hypothetical poster’s wording above, perhaps it’s time for you to settle back into a comfy chair for about 45 minutes and watch the replay of my recent Subversion 1.7 webinar.

This post is actually the final installment of a series of follow-ups to that webinar, fielding unanswered questions asked of me and my colleague Bob Jenkins during that event. (For the previous posts, see part 1, part 2, and part 3 of this series.) Hopefully, you’ll find my answers enlightening. And if not, you can at least take comfort in knowing that I’ve run out of questions to (try to) answer!

Q: What improvements have been made to the WebDAV write-through proxy? Currently, if the master server is down, the slaves don’t work either — has this been addressed in Subversion 1.7?

I’m sorry to hear that you’re having troubles with your WebDAV proxy setup. My own experience with WebDAV proxies using Subversion 1.7 so far is that if the master server is down, the slaves continue to operate, albeit in a read-only mode. You can checkout, query logs, and so on, but simply can’t commit new changes or modify revision properties. If you’re seeing different behavior when your master server is offline, there might be a problem with your particular deployment scenario or possibly even a bug in Subversion itself that needs to be reported to the community. Don’t look for any specific improvements to this feature that are unique to Subversion 1.7, though — all the improvements made to the WebDAV proxy code in the 1.7 timeframe (which were mostly minor bug fixes) have been backported to the 1.6.x line.

Q: Is there a plan for supporting mirrors as part of Subversion itself instead of forcing users to configure and maintain those things?

The Subversion core software doesn’t really concern itself so much with its own specific deployment. You won’t see Subversion modifying your Apache httpd.conf file automatically, or generating its own repository hook scripts, for example. There are just too many different ways to deploy Subversion, too many different operating systems and platforms and such, etc.

Fortunately, CollabNet TeamForge 6.1 provides pain-free mirror maintenance as a value-add beyond what the core Apache Subversion distribution offers. With TeamForge, you can administer multiple Subversion Edge instances, and even configure some of your repositories on one Edge server to act as write-through proxies for other ones in another Edge server. Honestly, it’s the slickest packaging of the WebDAV proxy feature that I’ve ever seen. Check out the TeamForge 6.1 press release and TeamForge product page.

Q: We are using Subversion with LDAP Authentication. What is the best way to manage role-based access for users and project members? Do we need to use Jeremy Whitlock’s python script (http://www.thoughtspark.org/node/26)?

Jeremy’s script is useful if you need to replicate your LDAP groups into Subversion’s stock authz-file access control mechanism. But many organizations find that Subversion and LDAP are happier together and easier to administer when deployed on the server under CollabNet TeamForge, which offers real role-based access control for Subversion repositories and LDAP integration. Can you say, “No more editing access control configuration files”?

Q: What is CollabNet planning on doing with respect to their cloud offering? When will it upgrade?

CollabNet’s Codesion Cloud Services is currently still deploying Subversion 1.6.17. (If you’re interested, you can always see which product versions are deployed by Codesion at https://help.codesion.com/View.jsp?procId=e875af1afcaa7fc8e573946dfcc6a225.) But I have it on good authority that within the next few months, the upgrade to Subversion 1.7 should occur.

Q: We just upgraded TeamForge 6.1.0. How do we upgrade to the new release of Subversion?

My understanding is that the forthcoming TeamForge 6.2 will be the first TeamForge vehicle to directly offer a Subversion 1.7 integration. That said, you should be able to use TeamForge 6.1 today with Subversion Edge 2.1 as your Subversion integration server, and that will give you server-side Subversion 1.7. Of course, you can upgrade your Subversion clients immediately — they’ll work just fine against your TeamForge 6.1 server.

Category Categories: Subversion Events, Subversion Server, Subversion in the Enterprise | View Comments

The answer to your Visual SourceSafe dilemma: FIVE things (we bet) you didn’t know about Subversion

Posted by Bob Jenkins on November 22, 2011

On November 8th, I presented the webinar, “The answer to your Visual SourceSafe dilemma: FIVE things (we bet) you didn’t know about Subversion,” with Arneh Eskandari, SQL Tools, Red Gate Software. We introduced five powerful truths about Subversion and Arneh performed a live demo showing how to source control your database in Subversion in less than five minutes.

During the webinar, we encouraged our attendees to interact with us by participating in polls and by entering questions for the live Q&A session that we had at the end of the presentation. As a result, we received many great questions that we just couldn’t get to during the live event so we have provided answers to the audience’s questions below.

If you missed the session live, you can watch the recording and download the slides. For more information about this topic, please download my whitepaper, Economics of Migration. We have also put together a whitepaper specifically on the Five Things We Bet You Didn’t Know About Subversion. I also encourage you to download CollabNet Subversion Edge as is the answer for easy installation, administration, security, and governance of your Subversion environment.

Don’t forget to register for our upcoming webinars. CollabNet offers multiple webinars a month that cover a variety of topics related to software development.

As promised, here’s the follow up to the live audience questions.

Q: What is your Codesion offering, is it still free (I’m suspicious of free lunches!)
A: While I like the idea of free lunches, I too am suspect when offered one. We still offer a free 30-day trial for Codesion, but after that it costs based on a price per user. We do offer a 10 user license of our Application Lifecycle Management platform, CollabNet TeamForge, for free though we do suggest you purchase support for those users.

Q: Where can you see the SVN Revision number?
A: There are lots of places where a Subversion revision number can be viewed. Perhaps the most applicable is the Subversion info command which provides you with the revision number that reflects what you last got from the repository for your local copy (i.e., working copy) or, if given a URL path to the root of the repository (rather than a path in your working copy), the latest revision number for the repository as a whole.

Q: who is a good contact point for researching SVN support contracts?
A: Assuming you’re talking about purchase a Subversion support contract, then I’d point you to http://www.open.collab.net/support/support-programs/subversion.html which outlines the various offerings. Or you can contact us directly about support and other topics at info@collab.net.

Q: How does RedGate Source Control resolve/prevent change conflict?
A: SQL Source Control gives you the option to resolve a conflict by keeping your changes or taking the other developer’s changes. To merge changes from two conflicting versions of an object – resolve the conflict and then manually edit the object to include the changes from the other version.

Q: Does SQL SourceControl allow you to configure directory paths for specific database items?
A: This isn’t configurable; it enforces a directory structure.

Q: Any obvious tips on improving SVN server performance, say if my server is 1000 miles away from our dev office and dev clients?
A: In such a situation, your performance is likely most constrained by the network architecture and purchased bandwidth. Do a network trace to see how information is being passed between the clients and the server and based on that see if you can optimize the traffic by reducing the number of hops, etc. Monitor traffic in and out of the server site to see if you’re maxing out the bandwidth you have. If so, then consider purchasing more bandwidth. Server performance is rarely really about the server as Subversion has pretty low demands on the hardware. Certainly you can monitor CPU usage and memory with the latter more likely to be maxed out and therefore another potential area to address. As a database application, Subversion can be impacted based on the performance of the hard drives used for the repositories.

There are also additional steps you can take based on determining what operations are having performance issues. If you find it is pretty much the checkout command (which is always going to be the slowest given that everything has to be passed and then Subversion creates a second copy to help with the performance of all other operations), then often you can just establish a “reference” working copy local to the developers and instead of doing individual checkouts, they can just copy that working copy to get started. If performance is an issue across all read operations, then you might consider establishing a local replica and using Subversion’s WebDAV write-through proxy feature.

Key is not to jump to any particular solution without doing good analysis. Very few organizations need to utilize the last option discussed and most just need some fine-tuning of their network.

Q: Any way to force an SVN server to issue read-only files, in a get-latest scenario? We like read-only, for various internal reasons.
A: Certainly. Subversion implements this type of functionality using a property, svn:needs-lock. Applying this property to a file means that a checkout will get that file in read-only mode. The user will need to get the lock on that file on that branch to have write access. You apply properties to new files via the configuration file on your client machines so make an entry there that wildcards the applying of the svn:needs-lock property to all new files with a default value of “*”. For your current files, you’ll need to apply the property to all of them and commit that change to the repository. I’ll stay off my soapbox on not making this the default for all types of files.

Q: Will the Red Gate tool work for cloud-hosted SVN repositories?
A: Yes. There is no reason why this would work any differently than with local repositories.

Q: My team is actually thinking about to migrate from SVN to VSS. But now I think we should not to do that, at all. At least, I’ll ask him to re-think about…
A: I definitely wouldn’t consider moving from Subversion to Visual SourceSafe given that the latter is not going to be supported past June. I’d be quite interested in why you were considering that move and might be able to help you be successful with Subversion. Feel free to respond to this posting and I’ll be in touch.

Q: We saw 1.7.0 was recently released. Should we use it? What’s in it?
A: I definitely encourage people to use the latest releases whenever possible. Open source projects operate differently than commercial tool develop in that process is never held hostage by the need to get the product out the door. That means that you don’t have to wait for 1.7.1 to feel comfortable that you’ve got a robust release. In addition to releases bringing in new functionality or optimizing existing functionality, they often include bug fixes to functionality that you are likely using on a regular basis so keeping up-to-date is important. It is also quite easy to do since you don’t have to migrate repositories to new releases so you’re only looking at upgrading the binaries (and your users are likely doing that already with the clients).

Release 1.7’s key focus was on a rewrite of the working copy structure to help both with performance as well as with increasing feature velocity moving forward. The metadata and pristine/base copy of what you check out are both moved to the top of the working copy with the metadata consolidated into a SQLite database. Other parts of this release include cutting down HTTP chatter, improving merge tracking, enforcing some best practices, enhancing change reporting, and a few administration features and improvements. I encourage you to view the webinar that I did with one of leading Subversion committers, Mike Pilato, to learn more.

Q: We are in a regulated industry and must have our history available. Can we migrate VSS with full history?
A: I’d still consider leaving history in VSS and archiving both the repository and the tool to satisfy this need. That said, it is possible to migrate with full history depending on the amount and kind of corruption in your VSS repository as well as the time and money you want to invest in the migration. People successfully migrate from VSS, with history, all the time using open source tools. If you want to pursue this option, we do have a unique migration tool at CollabNet that allows for a bit more of the environment to be accurately reflected in the resulting Subversion repository. One other thing, if you do choose to migrate your history, I’d recommend not migrating it into the production repository, but into a history repository. It is still a good idea to start things fresh after a move.

Q: We code mainly in C# and Java. Could/should we have those projects in the same Subversion repository?
A: You definitely could put them in the same repository as Subversion will revision anything that you can put onto a hard drive. As whether you should, well that would take knowing more about the projects and your organization. If the projects directly relate to one another (e.g., the C# defines the back-end of the application and the Java the front-end), then it may well make sense to have them in the same project. If there is no relationship, then different repositories may make more sense (e.g., repositories by platform).

Often repository layouts are determined by access permission commonality. If an organization treats all projects the same with the same group of users given the same permissions, then it may be best to have the projects in a single repository. If the access varies based on a different set of developers for each, then separate repositories is probably better. More often than not, organizations do separate repositories by platform.

Q: What service do you recommend to make the transition to Subversion easier and more productive?
A: I strongly recommend that organizations look at the Subversion Applied Workshop. While we frequently focus on migrating data, we often forget that we need to consider how our processes should be impacted in order to get the most out of our new version control tool and to avoid the possibility of trying to put a square peg in a round hole. An organization’s current version control process has been driven, to some extent, by what the legacy tool did well and did not do well. There is a need to go back to the core requirements, define the high level process needed to satisfy those requirements, and then apply Subversion Best Practices to implementing that process. That’s hard for an organization to do on their own since they are new to Subversion, but it is critical to being successful and happy with Subversion.

Category Categories: Open Source Software Development, Subversion Client | Tag Tags: collabnet, open-source, Redgate, SCM, subversion, svn, Visual Source Safe, VSS | View Comments

Eclipse Marketplace passed 1 million installations

Posted by Lothar Schubert on November 16, 2011

Last count was at 1,033,450. The marketplace now features an impressive list of 1,200+ plug-ins. #1 download (and favorite) is Subclipse, developed by CollabNet. Glad to see the strong momentum behind Subversion (and a bit proud too). The Eclipse plugin is actually quite easy to use, I’d encourage you to check it out. And when at it, also see the Eclipse desktop, and the related training video.

Category Categories: Subversion Client | Tag Tags: Eclipse, subclipse, subversion edge | View Comments

What’s New in CollabNet’s Distribution including Apache Subversion, Version 1.7

Posted by Adam Ambrose on November 1, 2011

Last Monday, I presented the webinar, “What’s New in CollabNet’s Distribution including Apache Subversion, Version 1.7,” with Mark Phippard, Director Engineering, Subversion and Integrations at CollabNet. We talked about the new features in Subversion Edge 2.1, the latest release of CollabNet’s Apache Subversion distribution. Specifically, we covered:

Browser based management console, and Subversion browser
Built-in update mechanism, for latest Subversion patches and features enhancements
New: Back-up services, and dump/load features for repository migration and upgrade.

We encouraged our attendees to come to the session armed with questions. As a result, we received many great questions that we just couldn’t get to during the live event so we have provided answers to the audience’s questions below.

If you missed the session live, you can watch the recording and download my slides. I also encourage you to download CollabNet Subversion Edge as is the answer for easy installation, administration, security, and governance of your Subversion environment. Also, don’t forget to register for our upcoming webinars. CollabNet offers multiple webinars a month that cover a variety of topics related to software development.

As promised, here’s the follow up to the live audience questions.

Q: What about Mac OSx? Any plans to support it?
A: Note that *client-side* Subversion has been supported on Mac OS for some time. Since Subversion Edge is used for setting up a Subversion *server*, we’ve focused on environments that are traditionally used for servers – Windows 2008, LInux, Solaris, etc.

Q: Can you commit to a replica repository? If not what the replica is used for?
A: A Subversion Edge replica has a write-through proxy enabled, so commits can be directed at the replica, and commits will be proxied through to the back-end repository master. Since the majority of Subversion transactions are read-only, the replica’s primary is meant for speeding up read access in remote locations, or for distributing read load across multiple replicas.

Q: What Linux distributions are supported?
A: Red Hat 5 is officially supported. The software runs fine on quite a distributions that we’ve seen – including CentOS, SuSE, and Ubuntu.

Q: Any tools for managing custom Subversion hooks?
A: This is on our roadmap. Of course, nothing prevents you from managing the hooks “manually” right now.

Q: Is there any repository migration support in subversion edge?
A: There are several choices for migrating a repository into Subversion Edge. You can point the repository directory to a directory that stores older FSFS-based repositories, and have Subversion Edge. You can also dump your old repositories (of whatever format), and load that dump file into a Subversion Edge repostory.

Q: Is SVN Edge meant to manage one repository (and optional replicas)? We have multiple repositories we were thinking of moving to an Edge server.
A: There is no fixed limit on the number of repositories that can be managed by Subversion Edge.

Q: Will there be a file/directory search function in the web UI?
A: Not currently planned, but feel free to bring it up in the forum, or add as a user request in our User Requests tracker: https://ctf.open.collab.net/sf/tracker/do/listArtifacts/projects.svnedge/tracker.user_requests

Q: will user properties like email be available via an API for use in my own maintainance scripts?
A: We are working on a Rest API right now. This sounds like a good requirement to have. If you have any other requests for info available via API, please let us know on the forum or in the User Requests tracker: https://ctf.open.collab.net/sf/tracker/do/listArtifacts/projects.svnedge/tracker.user_requests

Q: What is the status of backward-compatibility with package containing Subversion v.1.6? Any serious limitations?
A: Subversion maintains backward-compatibility across all its versions.

Q: Is there a way to get email list of all users that are added in edge?
A: See the question on the APIs, above.

Q: Do you support Red Hat Enterprise 64 bit?
A: Yes!

Q: What is your technical roadmap for supporing Mac OS. We intend to develop on Mac and deploy to Red Hat.
A: This is fully supported today, as answered above. The Subversion client has been supported on the Mac OS for a long while – we have many developers here who use Mac OS. The Subversion Edge *server* can be on a different OS, and Red Hat is officially supported by us.

More questions? Post them in the comments section below.

Category Categories: Subversion Client | View Comments

Subversion 1.7 Q & A, part 3

Posted by C. Michael Pilato on October 21, 2011

This is the third of, I predict, four posts containing answers to questions asked of my colleague Bob Jenkins and I during our recent Subversion 1.7 webinar. (For the previous posts, see part 1 and part 2 of this series.) Today’s batch of questions begin to deviate a bit from the primary topic of Subversion 1.7, but that’s okay — maybe one or more of these questions were on your mind, too.

Q: How does Subversion 1.7 compare with Git and Mercurial?

I think a full comparison of Subversion with Git or Mercurial might be a bit more of an endeavor than I’m willing to engage in at the moment, so I’ll shoot for a mile-high approach.

Subversion offers centralized version control, meaning that the primary storehouse for the version history is a repository in some central location, accessed by clients whose direct interactions are solely with the repository, not with each other. The Subversion client maintains only enough information as required to complete those interactions with the repository for the purposes of version control. Information is only shared between clients after passing through the central repository — a classic hub-and-spoke model.

Git and Mercurial offer distributed version control. The primary storehouse for version history in a DVCS is still a repository, but there’s no single central repository. Instead, each client has its own private repository against which it primarily operates, and the business of sharing information between clients is actually done by sharing information from one client’s local repository with another client’s local repository. Centralization of information can occur by policy, but is not a required component of this point-to-point model.

There are pros and cons to each type of system, and the Web is full of write-ups about these. Sadly, most such write-ups that I’ve seen tend to be quite biased, so as you further research this topic, you’ll need to crank up your FUD filter. But in general, I believe it can be safely said that the DVCSes excel in everyday performance and in the maturity of their merge algorithms. Centralized version control systems, on the other hand, claim ease-of-use and enterprise-friendly aspects such as path-based access control and, indeed, centralization of information itself as their high points.

Q: Can you create local topic branches in Subversion without sharing to the central server?

You cannot. This is precisely the sort of thing that a DVCS tool allows, but for which Subversion has not been designed. That said, the Subversion developers are exploring some related features (shelving and checkpointing) for future releases which we believe will go a long way toward alleviating the need to use a full-blown DVCS tool just to get some more client-side support for locally checkpointed changes which will be committed to the central server at a later time.

Q: Will Subversion be a distributed VCS some day?

The Subversion developers have consistently agreed that the version control landscape is not really in need of yet another contender in the DVCS arena, while there remains a need for solid centralized version control. Our project’s goal is to be the very best centralized version control system — no more, no less. Efforts spent completely re-architecting Subversion as yet another DVCS would be ill-invested.

Q: Is there a limitation on the size of any given branch in Subversion?

Not really. There are certainly some things that you could do in Subversion that would make operations slower — placing a gazillion files into a single directory, for example — but there’s nothing about those scalability characteristics which is specific to branches. After all, branches in Subversion are just directories.

Q: How do we backup Subversion? How can we test restores of those backups?

There are many different ways to backup your Subversion repositories. You’ll want to determine your needs as far as backup goes: do you need full backups, will incremental ones suffice, or do you prefer a combination of both? Sometimes the answers to those questions are found in what tools and resources are available to you. Sometimes they are found by examining your restoration needs: do you need near-immediate restoration in a failover scenario, or is a longer downtime event an acceptable cost in your situation? Version Control with Subversion covers various different approaches to backup in its chapter on Repository Administration. See http://svnbook.red-bean.com/en/1.6/svn.reposadmin.maint.html#svn.reposadmin.maint.backup for details.

In terms of testing restoration, I would suggest using the ‘svnadmin verify’ command. Actually, I’d recommend occasionally using that command against any full backups that you have, too, so that if corruption of a backup occurs for some reason, you can catch that before needing to rely on that backup.

Users of CollabNet Subversion Edge will be pleased to learn that Subversion Edge 2.1 — which bundles Apache HTTP Server, Apache Subversion 1.7, and ViewVC with an easy-to-use Subversion administration console — offers automated backup capabilities. (Not on the Edge? Download it today at http://www.collab.net/getSVN/!)

Q: I need CollabNet certified binaries, but don’t really want Edge. What are my options?

CollabNet continues to produce certified Apache Subversion binaries which are distinct from our Subversion Edge product. Visit http://www.open.collab.net/downloads/subversion/ as a starting point for locating all of our available packages. There, you can see package offerings by operating system, as well as an admittedly somewhat non-obvious link to http://www.open.collab.net/downloads/subversion/svn-other.html, where our non-Edge server packages may be found.

Q: Is your support staff US-based?

(That’s an odd question for a technical webinar, but …) The short answer is, “Yes, partially.” CollabNet is an industry leader in globally distributed development for a reason: for over a decade, we’ve been successfully practicing globally distributed development using the very same platforms and tools that we offer to our customers! Headquartered in California, CollabNet currently has six additional offices located around the world, empowering us to boast of 24×7 product support delivered by staff in several time zones.

Category Categories: Subversion Client, Subversion Events, Subversion Server, Subversion in the Enterprise | View Comments

Subversion 1.7.0 Released

Posted by Mark Phippard on October 11, 2011

Subversion 1.7.0 has been officially released today. With the release of Subversion 1.7 comes the release of Subversion Edge 2.1.0. This release of Subversion Edge brings you the server binaries for Subversion 1.7.0 as well as the latest release of Apache httpd. In addition to the inclusion of the Subversion 1.7 server binaries this release of Subversion Edge brings a number of other nice improvements including the addition of a complete 64-bit Windows binary stack. As with all previous Subversion Edge releases you can simply update your existing installation from the Subversion Edge web console. There are no other special considerations, the update mechanism handles all details.

I encourage all users to update their Subversion Edge servers to this release so that you and your users can enjoy the new features brought from this release as well as the improved performance and fixes that comes with Subversion 1.7. Look for updates to your favorite Subversion clients to follow shortly.

Recent Posts

Authors