|
|
< Day Day Up > |
|
4.4 Adding a Project to the CVS RepositoryWe'll start using CVS by seeing how to add a new project, Ch04_01, to the CVS repository. After this project is in the CVS repository, anyone with access to the repository can check it out and work on it. You can see this sample project in Example 4-1; this sample code does nothing more than display the word "Hello". Example 4-1. A sample projectpackage org.eclipsebook.ch04;
public class Ch04_01 {
public static void main(String[] args) {
System.out.println("Hello");
}
}
4.4.1 Creating a Repository Location
After you've created a
project, how do you add it to the CVS repository? You first have to
let Eclipse know about the repository, so select Window Figure 4-2. Connecting a CVS repository to Eclipse Here, enter the name of the CVS server (usually the name of the computer that hosts the server), the repository path, the username and password, and specify the connection type (here, we'll be using the pserver protocol). Then click Finish to add the new repository to the CVS Repositories view, as you see in Figure 4-3. Figure 4-3. A new repository in the CVS Repositories view Congratulations—now you've connected a CVS repository to Eclipse. The next step is to start sharing your new project.
4.4.2 Sharing Projects
To add the
Ch04_01 project to the CVS repository, you can use
the built-in support for CVS in Eclipse. Open the Java perspective,
right-click the project you want to share, and select the
Team Figure 4-4. Specifying which repository to use In this dialog, make sure the "Use existing repository location" radio button is selected, and select the repository you've already created. Click Finish to add the project to the CVS repository.
The Share Project operation adds the project to the CVS repository and also opens a Synchronize view that overlaps with the Console view. The Synchronize view lets you synchronize files, but it's not of much use to us at this point; we'll see how to work with it later in this chapter when we synchronize our local code with code in the repository that's been changed by someone else.
4.4.3 Committing FilesSo far, we've just added the Ch04_01 project to the CVS repository; now we've got to start checking in some files. There are two steps here: first, you add the file to CVS (which just notifies CVS of the file but doesn't actually upload the file), then you commit it (which makes the file appear in the CVS repository so it can be shared). You can add individual files by
right-clicking them and selecting the Team However,
there's an easier way. Eclipse gives you a shortcut
here—just right-click the project in the Package Explorer, and
select Team
To verify
that the project is connected to the CVS repository, select
Windows Figure 4-5. Verifying CVS connections Switch to the CVS Repository Exploring perspective now, as you see in Figure 4-6. You can see your entire project, now the Ch04_01 CVS module, in the repository's HEAD section, which is the main development stream. Also note the CVSROOT directory, which holds CVS administrative data, and the Branches node, which will hold any files in other branches of development. Figure 4-6. Examining files in the CVS repository 4.4.4 Checking Projects Out
How does someone else check
out your new CVS module? To check out a module, he'd
first create a connection to the repository in the same way as we
have—by right-clicking the CVS Repository view, selecting
New He can then open the Repository view to explore the files in the repository. To check out the Ch04_01 module, right-click the module in the Repository view and select the Check Out As item from the context menu, opening the Check Out dialog you see in Figure 4-7. Figure 4-7. Checking out a project In this case, clicking OK checks out the Ch04_01 project and tries to build it. If you're sharing an Eclipse project and each CVS module has its own Eclipse .project file, you can simply select the Check Out As Project item from the Repository view's context menu, which will check out an Eclipse project and build it locally. If your code isn't in a project of a kind that Eclipse can recognize, it will ask you what type of project to create; select the Java entry, followed by the Java Project entry. 4.4.5 Updating CodeSo what if you and other members make changes to the files in the Ch04_01 project and save them? For example, say you change the code from this, where we're displaying "Hello": public class Ch04_01 {
public static void main(String[] args) {
System.out.println("Hello");
}
}
to this, where we're displaying the message "Hello there": public class Ch04_01 {
public static void main(String[] args) {
System.out.println("Hello there");
}
}
When you make these changes and save the file Ch04_01.java, you'll see a ">" appear in front of various files in the Package Explorer, as you see in Figure 4-8, indicating there are outgoing changes that have yet to be committed. Figure 4-8. Changing a file in the CVS repository You could commit your changes to the CVS repository, but, as a general rule, it's a good idea to first check and see how your changes will be received. Say, for example, that someone else has already checked out the same code and modified it to display the message "No worries.": public class Ch04_01 {
public static void main(String[] args) {
System.out.println("No worries.");
}
}
He's committed the
changes by right-clicking the file in his version of Eclipse and
selecting the Commit item, so his version of the file is now version
1.2. With changes like this being made to the code, you can see why
it's a good idea to check what other changes have
been made before committing a file. To check on changes that have
already been made to the file you've checked out,
right-click it and select the Team Figure 4-9. Updating a changed file If there was no conflict, any changes would simply have been merged into your version of the file. But since both you and the other developer have changed the same line, there is a conflict. The CVS support in Eclipse indicates that there's a conflict by listing both versions in your code with some added CVS markup: public class Ch04_01 {
public static void main(String[] args) {
<<<<<<< Ch04_01.java
System.out.println("Hello there");
=======
System.out.println("No worries.");
>>>>>>> 1.2
}
}
To get more information,
right-click the changed file, Ch04_02.java, and
select the Team Figure 4-10. Looking at the resource history 4.4.6 Comparing Code with Local History
To make it a little clearer
as to what CVS-generated changes have been made in longer files, you
can check Ch04_02.java against its local
history, which is a useful thing to know. To compare a file against
its history, right-click that file and select Compare With Figure 4-11. Checking a file's local history 4.4.7 Committing CodeBefore you commit a file, it's up to you to resolve the conflict that the update has revealed. In this case, we're going to accept the other developer's version of the code, but with modifications—instead of "No worries.", we'll display "No worries at all.": public class Ch04_01 {
public static void main(String[] args) {
System.out.println("No worries at all.");
}
}
Now right-click
Ch04_02.java and select Team Figure 4-12. Committing a file Click OK to commit your changes to the CVS repository. Doing so creates version 1.3 of the file. And that's all you need—now you've committed a new version of your code to the CVS repository. We've gone through the whole cycle now—checking code in, checking it out, updating code to check on changes made by other developers, and committing it. There's also another way to update your code if the differences between your version and the repository are fairly extensive: you can synchronize your code. 4.4.8 Synchronizing CodeWhen the differences between your code and repository code are relatively minor, an update is fine. But when the differences are substantial, it's better to synchronize. Synchronizing with the repository lets you compare changes that have been made side-by-side in an easier format than the update merge format. For example, say that someone else works on the same file that you're working on, Ch04_01.java, and adds a new line of code and then commits her file as version 1.4: public class Ch04_01 {
public static void main(String[] args) {
System.out.println("No worries at all.");
System.out.println("Got any problems with that?");
}
}
To synchronize your code (version 1.3) with
the new version of Ch04_01.java (now at version
1.4 in the repository), right-click the Ch04_01
project and select Team Figure 4-13. Synchronizing a project When you first synchronize with the repository, you'll see the name of the files where there are differences marked with a stubby red double arrow (which looks almost like a diamond in Figure 4-13) in the Synchronize view. Double-clicking a file so marked opens the full display you see in Figure 4-13, where you can compare the repository version of the file (version 1.4) to your version (version 1.3) directly in the Java Source Compare view at the bottom of the window. Note, in particular, the line connecting the two code boxes in the Java Source Compare view and the small white box in the middle of that line. If you let the mouse hover over that box, it'll change into a button with a left-pointing arrow. Clicking that arrow will import the change into your version of the file, making the synchronization process a little easier. After you've synchronized your version of the code with that in the repository, commit your changes back to the repository. In this case, the repository file has been changed since the last time we synchronized/updated with the repository, and the Synchronize view opened in incoming mode (as you can see in this view's title bar in Figure 4-13), which displays the changes in repository code. There are three such modes in the Synchronize view:
You can select the Synchronize mode with the buttons you see at right in the Synchronize view's title bar. In Figure 4-13, Eclipse saw some incoming changes and automatically selected incoming mode, which means the incoming mode button is down. To the right of that button is the outgoing mode button and to the right of that button is the incoming/outgoing mode button. For example, say that you've changed the local version of Ch04_01.java so that instead of displaying the message "No worries at all.", it displays "No worries at all today!": public class Ch04_01 {
public static void main(String[] args) {
System.out.println("No worries at all today!");
}
}
Now when you save these changes locally and synchronize, selecting outgoing mode, you'll see your local changes compared to the repository version, as in Figure 4-14. Figure 4-14. Outgoing mode These modes are designed to let you filter the changes that have happened to make synchronizing/updating more tractable. If there are a lot of changes going on, make sure you synchronize/update frequently—although it can feel like an unpleasant task, it's necessary when you're working in teams, and, if you wait too long, merging with the repository code can become just about impossible.
4.4.9 Creating a PatchNot everyone you deal with is going to have access to your CVS repository. To update those users without changing the version number of the software, you can create a patch. For example, say that you added this line to your example code locally but didn't change the code in the repository: public class Ch04_01 {
public static void main(String[] args) {
System.out.println("No worries at all.");
System.out.println("Got any problems with that?");
System.out.println("Didn't think so.");
}
}
You can create a patch that will convert the standard code for this version to the new form of the code. When you create a patch, Eclipse will compare your local code to what's in the repository and create a patch file holding the differences. To create a patch to let users of your code
come up to speed without needing access to the CVS repository, save
the modified file locally, right-click it, and select Team Figure 4-15. Creating a patch You can save the patch file where you want; in this case, we'll save it as a file named Ch04_01Patch in the workspace. That's all you need; click the Finish button to save the patch. This creates the file Ch04_01Patch with these contents—as you can see, this is simple text, suitable even for emailing (note that the new line of code is marked with a +, which means Eclipse will add it to the code you're patching): Index: Ch04_01.java
===================================================================
RCS file: c:/repository/Ch04_01/org/eclipsebook/ch04/Ch04_01.java,v
retrieving revision 1.4
diff -u -r1.4 Ch04_01.java
--- Ch04_01.java 28 Oct 2003 21:13:46 -0000 1.4
+++ Ch04_01.java 29 Oct 2003 17:34:54 -0000
@@ -17,5 +17,6 @@
public static void main(String[] args) {
System.out.println("No worries at all.");
System.out.println("Got any problems with that?");
+ System.out.println("Didn't think so.");
}
}
To apply the new patch to code that has not
yet been patched, right-click the file to be updated in Eclipse and
select the Team Figure 4-16. Applying a patch Browse to the patch file and click Next, opening the dialog you see in Figure 4-17. Here, you can review the changes the patch will create in your local version of the file. As you can see, Eclipse is proposing to add the line System.out.println("Didn't think so."); to your code. Click Finish to apply the patch. Figure 4-17. Configuring a patch Applying the patch adds the new line of code to the local version of the file, as you see in Figure 4-18. The version number of the file wasn't changed, but your code was. Using Eclipse in this way automates the entire patching mechanism. Figure 4-18. The new patch has been applied 4.4.10 Tagging Versions When
you create a milestone version of your code, you can tag it with a
version label, which will make CVS store that version so that you can
access it at will later. To tag a project with a version label,
right-click the project and select Team Figure 4-19. Tagging a version In this case, we're going to tag the current version of the project as FirstSafeBuild, so enter that name and click OK. Version labels must start with a letter, and they may not include spaces or these characters: `$,.:;@|'. After tagging the current version with this name, you can find it in the Versions node in the CVS Repositories view, as you see in Figure 4-20. Figure 4-20. Examining a tagged version You can check out
a tagged version of a module by right-clicking it in the CVS
Repositories view and selecting context menu items such as Check Out
as Project, as with any other CVS module. Alternately, you can
right-click a project in the Package Explorer and select the Replace
With Figure 4-21. Replacing the current project with another version Tagging a project with a version label like this is very useful because it lets you store a snapshot of the project that can be retrieved by name later. 4.4.11 Creating BranchesBesides storing versions, you can also create new branches, which act as alternate streams of development. For example, you might want to create an Internet-enabled branch of your software for testing, so you'd split a new branch off from the main development tree to do that. To create a branch, right-click a
project and select Team Figure 4-22. Creating a new branch If you leave the "Start working in the branch" checkbox checked, you'll start working with the branch's code immediately. Alternately, you can check out a branch from the CVS Repository view, as you see in Figure 4-23. Figure 4-23. Exploring branches
If you want to merge a branch back into the
main development stream, right-click it in the Package Explorer and
select the Team This finishes our chapter on teamwork using CVS. A natural part of developing code with Eclipse is to share that development with others in teams, and, as you can see, Eclipse is up to the task. |
|
|
< Day Day Up > |
|
Open Perspective