In the final video of this chapter, you can talk a little about concepts like sharing files with your team, merging changes, and whether or not you'll need to lock files to "keep them safe". We'll also answer a few questions you might have about working with multiple projects and whether or not it makes sense to use version control if you're a solo developer on a project.
- [Instructor] I'll close out this chapter with the answers to a few questions you might have based on what we've talked about so far. The first thing people often wonder is whether or not you can lock files in a version control system. You might be nervous about multiple people working on the same file. After all, if you've never used a version control system before, you probably have all sorts of angry stories about losing changes because someone else wrote over them. The best answer is you don't have to worry about file locking if you have a system that can merge changes. All of your bad experiences before were because you only had full backups of entire files and your changes were all or nothing.
With a version control system, the checkout update commit process lets everyone safely change the same file at once. Now if you do want to lock files for some reason, Subversion does have a mechanism for locking single files for a specific user. You can't lock an entire project all at once, but you can issue a lock on one or more files if that makes you feel better. The other reason people ask about file locking is because they're worried about changes to binary files. Merging changes to a text file is one thing, but in most cases you can't really merge two changes to a binary file.
If two people make changes to the same jpeg image, for example, merging just their changes together will probably result in a corrupted file or at least a really funny looking image. The answer is you can't merge binary files. Luckily, Subversion does a good job of auto-detecting which files are binary and which ones are text and handles each file type differently. Text files will get merged and binary files will get replaced with new copies. Because of this, sometimes you might want to store binary files to a separate project so they can be managed separately.
Or if you have graphic designers who are working on images for your software. Maybe you can give them their own branch so their changes can be merged back into trunk as needed. Another question is whether or not you're required to have a server to manage your version controlled project. With a system like Subversion, yes you do. This is because the server does a lot of work and it also acts as the master copy of your project files. You only store one version of the files on your local machine, but the server has all the versions of the files. However, you can easily set up a Subversion server on your local machine.
It doesn't have to be a dedicated server and it takes very few system resources. If you're working alone and not on a team, this might be a good option for getting started. We'll show you how to setup your own server in the next chapter. I'll also point out that a distributed version control system like Git generally does not require a server for reasons we discussed at the beginning of this chapter. This is one of the things that makes Git a very appealing system for developers who are just starting out, no server required. So you do need to have a server when you use Subversion but do you always need access to the server? The answer is no.
Remember that you always work on a local working copy of your code. The only time you need access to the server is when you're making a commit or getting information from the server like an update or a history request. Otherwise, you can be completely offline while you work on the code. You only need to connect when you need the server for something. We've talked about having multiple projects in a single repository, but you might be wondering if you can have multiple repositories on a single server. Yes, you can. If you want to have a separate repository for different customers or a separate repository for different software products, you can host them all on the same server.
If you start with all your projects in one repository and you decide later you want to move some of them to a different repository, you can do that too. I will point out that we don't talk about server administration in this course though. This course is geared more toward using version control as a developer not as an administrator. What about having the same project on multiple servers? For example, what if you're working with a customer who has their own Subversion server and you want to manage the project on your server and on their server at the same time. The short answer is no you can't really do that.
There's some solutions that allow you to mirror two Subversion servers, but it's not a very simple process and your customer probably won't want to do that. Ultimately, you should just use a single server for a particular project and try not to make Subversion work in a way it's not designed to work. As an interesting side note, there is a program called git-svn that allows you to use both Git and Subversion on the same project. Some people like to use this technique to manage all their project changes locally and then send them out to the Subversion server separately.
We'll talk briefly about this technique at the end of the course. I've mentioned this before but it's worth repeating, you can use any editing software you want to modify your project files. Since the version control system uses a local working copy, all you're doing is editing local files on your computer. Your editing software doesn't have to know anything about version control systems and all you need to have is a client that can commit or update the files when you're done editing them. That being said you're life will be a lot easier if you use a development environment that is aware of version control so your client is integrated with your programming tools.
In this course, we use Eclipse for both editing and talking to the Subversion server but we also have examples of using clients to operate directly against your local files on the file system. Another point worth mentioning, if you have a version control system, does that mean you still have to talk to your colleagues? Yes, communication is good. Working in your own branch and merging changes locally can make it feel like you're working in a silo, but that doesn't mean that all your changes are magically coordinated. All you see if the changes your team makes after they make them.
It doesn't tell you what they're working on or what they're planning to do. By the same token, it's kind of good for your teammates to know what you're working on too. It's really important not to surprise your teammates with your changes just like you don't want them to surprise you. Communication is especially important when you're making large commits or merging branches with lots of changes because the more changes you commit, the higher the chances that someone will run into a change conflict. Also, people need to take your changes into account when they're testing. Preparing a release takes extra communication too because everyone needs to decide which changes are going into the release and which ones are going to be held until later.
You might have a lot of different branches that need to be merged into trunk and this isn't always a painless process. But what if you're working by yourself? Does it make sense to use a version control system if you're not on a team? Yes, absolutely, version control systems are fantastic tools for solo developers. At a very basic level, it's a great way to back up your code and as we've discussed over and over, you're not just making copies of your code, you're also giving yourself a way to go back in time and see exactly what changed and when.
Also, once you get used to branching and merging to manage your features and changes, you'll love it. It really takes the stress out of making changes if you know you can undo them automatically and easily.
- 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