This video is a brief discussion of forwards and backwards compatibility concerns with Subversion servers and SVN clients, like whether you can use older versions of the clients with newer versions of the server, or the other way around. We'll also talk about why it's bad to mix versions of the client on your local workstation.
- [Instructor] Now I'll talk a little about compatibility between different versions of SVN software. What if you have an old version of the SVN client, say version 1.7, and you want to talk to a newer version of the server, like 1.9. In general, that works just fine. You might not have access to some of the newer server features, but you probably won't notice any problems. The subversion team does a really good job at making sure the new servers are backwards compatible with older clients. The most noticeable thing you might be missing is new authentication options that are on the server, but aren't available on the client, but those types of changes are few and far between.
If you can upgrade your client to match the server, though, it's almost always a good idea. Not only do you get new features, but you might get some performance improvements, too. What if you have an older version of the server and a newer client? That normally works okay, too, just like before the older server won't have access to any new client features that are available, but normal day-to-day operations will be fine. And I don't know if an SVN feature has ever been dropped from a new version of the client, so you're safe in terms of using old features, too. That being said, it's a great idea to upgrade your server when you can if you're more than one minor version behind.
You usually get some great performance improvements with server versions, along with new features. Server upgrades are a little more painful than client upgrades are, though so, and it usually take a bit of planning and work to make sure nothing breaks. Now you definitely can run into problems if you have multiple different versions of the SVN client on your workstation. That's just asking for trouble. Let's say you have version 1.6 of the command line tools, and a TortoiseSVN version that corresponds to version 1.9. If you use the command line tools, and TortoiseSVN to manage the same local working copy of a project, things can break, don't do that.
You can manage a local working copy using different clients, but you have to be really careful to use clients that are compiled using the same version of SVN code, so the working directory files stay safe. We talked about the SVN kit and that JavaHL connectors in Eclipse, this is actually a good argument for using the JavaHL connector. If you're also using a local SVN client to manage your Eclipse projects, you might have fewer problems if you use JavaHL, because that's just a wrapper around the SVN binaries. Again, if you do that, just be really careful about which versions you're using.
I'd also like to point out that the servers we've installed using Visual SVN and Apache Subversion are set up for testing only. There's a lot more configuration you need to do if you want these to be true production servers, especially in terms of security. This has to do with setting up user accounts, as well as securing the server itself. Setting up a truly production-ready SVN server is well beyond the scope of this course, so we're not going to talk any more about server administration in this tutorial. If you need to set up a server for your team, there are plenty of resources on the internet.
- Trunks, tags, and branches
- Checkout, commits, and revisions
- Merging, locking, and working with a team
- TortoiseSVN on Windows
- SVN integration with Eclipse
- Connecting to a project
- Creating a new Java project in Eclipse
- Connecting to an existing Java project using Eclipse
- Dealing with projects that move to a new location
- Making changes and creating branches
- Tracking changes and dealing with conflicts
- Creating a release