using cvs inside eclipse
TRANSCRIPT
Using CVS inside Eclipse
1
1. Basics 1: Getting Started 2. Basics 2: Create a project from scratch 3. Basics 3: Import an existing set of project files into CVS 4. Basics 4: Check out a project from the CVS repository 5. Basics 5: How to switch workspaces 6. Basics 6: Setting up the Eclipse interface for working with
CVS7. Branching Tutorial 1: Branching Strategies 8. Branching Tutorial 2: Create the Workspace & Project 9. Branching Tutorial 3: Share the Project 10. Branching Tutorial 4: Create a Branch 11. Branching Tutorial 5: Work in the Branch 12. Branching Tutorial 6: Edit the main Trunk 13. Branching Tutorial 7: Merge changes back to the Trunk
2
Beginning Eclipse CVS - Basics 1: Getting Started
Eclipse is an open-source software development platform or IDE that has CVS (version control) functions built-in. Although Eclipse was originally built for Java development, it is very useful for working in other languages as well because of it's open plugin-based architecture. It is often used as the foundation for new applications because it is so easily extended. This series will focus on the basics of using Eclipse for for version control, for web designers or beginning developers.
Why use Eclipse and CVS?
Eclipse is a great development environment for teams. It is extremely flexible and can be customized to work the way each person prefers, with strong team functionality. One of its many useful features is CVS version control. Version control applications like CVS not only help prevent overwriting other team members' work, but it maintains an exact record of every change ever made, and who made each one, allowing comparisons between versions and rollbacks when necessary.
Version control also allows team members to work on different code branches at the same time. Some team members can work on a particular feature or flavor of the project without affecting the others, until the change has been thoroughly tested and is ready to merge back into the main trunk of the code. You'll note the tree metaphor here, and it is commonly used in describing code versioning situations.
Why is this tutorial needed? When I first started out with Eclipse, I had very little experience with IDE's of any kind, and found it quite difficult to understand what was going on because the interface is so flexible and seemed to change at every click. Most tutorials on CVS assume some development experience. This tutorial is for beginning web developers who might be experiencing the same confusion and want to use Eclipse mainly for version control and team coordination.
CVS works by storing information about your files in a repository on a server, along with the files themselves. When you make changes to the file, all those changes are tracked, along with any comments you make about each change, and the file version number is updated. This tutorial assumes you have a repository set up somewhere, but if you don't, try CVSdude.com for CVS hosting.
3
Choose a workspace
Create a new empty folder on your local drive or on the server you are using f. Give it your project name, or call it workspace, or something similar. Then launch Eclipse, and it will open the Select a workspace dialog. Select the new folder you just created and click OK.
If you had a default workspace selected, Eclipse will not ask you to choose one - it will simply open the workbench view. If that default workspace is open and you want to change to a new workspace for your new branch or project, you will want to switch to a new workspace. (Instructions to come soon)
Beginning Eclipse CVS - Basics 2: Create a new project from scratch
Eclipse Terminology-"Perspective":
The word "Perspective" is used to denote a window panel in Eclipse with a specific purpose. There are Eclipse perspectives for different functions, like the Resources perspective for viewing workspace assets or resources, the Team Synchronization perspective for viewing CVS synchronization information, and the CVS perspective for viewing CVS Repositories, to name a few.
1. Open up the CVS perspective in Eclipse by selecting Window > Open perspective > Other > CVS Repository Explorer from the main menu.
The CVS perspective is open on the left in the image below.
2. Create a new Repository Location:
4
Right click on the left window. Select New : Repository Location from the menu that appears.
3. Fill out the form with the correct login information
5
4. Create a new project: File : New : Project
5. Click Resource to open your Resource perspective. You should see the project you just created. If you were to look at your workspace using Windows Explorer (PC) or Finder (Mac), you would see a new folder inside it with your project name.
6
6. Now add the project folder structure you just created to the CVS repository. Right click on the new folder and select Team : Share Project
7
7. Select the CVS repository location you just set up.
8. Follow the steps presented and it will commit your new project to the repository. Choose a module name (often the project name will do).
8
9. Review and commit the resources (in this case, just a folder and a project file) to the repository.
9
10. Click Finish, and you will be returned to the Project Explorer view (Resources Perspective ).
10
Beginning Eclipse CVS - Basics 3: Import an existing set of project files into CVS
1. Once you have created a workspace, you need to add files to it somehow. If you already have existing files that you want to use in your project, you'll need to import them. You can also check out an existing project from CVS or import files from a zip archive, among other possibilities.
1. Create a new, empty project in your workspace to import the files into: in the Resources Perspective, select New Project from the File menu.
2. Enter a project name and leave Use default location checked. It is usually set to the root of your workspace. It is possible to have projects outside the workspace, but it is simpler to have all your projects and files inside a workspace. You canhave multiple workspaces, however.
11
3. Select Import from the File menu. The Import dialog will appear.
12
4. Select General : File System.
5. Browse to the directory containing the files you want to import. Click Choose.
13
6. Once you select the directory, you'll notice this warning:
7. The warning will disappear when you check the box next to the directory listed. Leave Create selected folders only selected. At this point it is set to import every file and folder within "portal." If you were to select Create complete folder structure, it would also create the parent folders of "portal."
8. It is possible to restrict the files that will be imported by type. You can choose from the types listed, or enter your own choices in the Other Extensions box. Use this format:
jpg,gif,png
14
9. If you filter the file types, the check next to the folder name turns to a minus-sign indicating a partial selection has been made.
15
10. The project will appear in your workspace, in Project Explorer.
11. To add the new project to the CVS repository, right click (Control-click on Mac) the project folder, and select Team : Share Project
16
12. Select the repository you want to use and click Next >
13. It will display a list of all resources that have not yet been committed to the repository. Click Finish. It will ask you to enter a comment each time you commit files, so enter "Sharing Project to CVS" or something similar. Click Finish to complete the process.
18
Beginning Eclipse CVS - Basics 4: Check out an existing project from the CVS repository
Select Import from the File menu.
5. Eclipse CVS for beginners: How to switch workspaces
You can set up multiple workspaces in CVS. This is useful for maintaining DEV, TEST and PROD environments, syncing them all to the project in the CVS repository, or it can be used to maintain differerent projects. You can also have more than one project folder in a single workspace.
19
1. Select Switch Workspace : Other from the File menu.
20
2. Select the folder you want to use as your workspace for this project.
Eclipse will close and reopen, showing the new Workspace's project folder(s) in theProject Explorer view.
21
6. Beginning Eclipse CVS - Basics 6: Setting up the Eclipse interface for working with CVS
Eclipse can be used for many types of development tasks. As a result the interface is almost infinitely customizable. This can be confusing. When you first open it, you will probably see only functions related to Java development, as shown below:
If you are not developing Java applications, but want to use CVS primarily to manage a website or web application you may want to rearrange the interface to better suit your purposes. What follows is an example of setting Eclipse up to manage an ASP/HTML web application.
22
1.Eclipse uses the word "Perspective" to describe a layout of panes in the Eclipse window that is geared to providing a specific type of functionality. There are perspectives for editing and debugging Java, for managing resources and assets of any type, for viewing the contents of a CVS repository and for synchronizing local resources with the CVS repository. We will be opening the CVS Repository, Team Synchronizing, and Resource perspectives.
2. First we'll remove the Java button by right-clicking it and selecting Close.
3. Click the icon, and select "Other" from the dropdown menu.
4. Select Resource from the list and click OK.
23
5. Repeat with Team Synchronizing and CVS Repository Exploring.
24
6. The correct buttons will appear on the tab.
7. To make more room for your links, click in a blank area on the tab (cursor will change to the one shown) and drag toward the left to enlarge it.
You may of course create your own perspectives to better suit your needs:
1. Open an existing perspective that is closest to what you will want, and modify it by adding, closing or moving the views (panes) around in that perspective's window. (Use Window>Show View to open additional views, click on the X in the view's tab to close it).
2. Save the new layout by clicking Window > Save Perspective As...3. Type a new name for the new perspective and click OK. The new name will now
show up in the Window > Open Perspective menu.
25
Beginning Eclipse CVS - Branching Tutorial 1: Branching Strategies
NOTE: This section of the Eclipse CVS tutorial is based on Paul Glezen's article on the Eclipse website: Branching with Eclipse and CVS, and is used with his permission under the terms of the EPL license. The changes I am making to his version are mainly to expand it with more step by step images and explanations, and integrate it with my own beginner tutorials in an attempt to make it more accessible to beginners and designers. Experienced developers will probably prefer to work from Paul's version.
When working together in a team, developers often need to isolate code lines from each other to prevent conflicts. Besides the possibility of simply stepping on each other's toes and overwriting new versions with older versions, different functions under development may conflict with each other while being tested.
To prevent this, projects can be developed in concurrent paths, with one path being devoted to the main line of development and others set aside for testing new features or bugfixes. One line can be kept stable or close to stable, with others not yet even in testing. Several common configuration strategies are used for team collaboration on software development.
The field of Software Configuration Management is the discipline of designing methods for effective development team collaboration and version tracking that promote productivity and reduce risk. Branching and merging strategies are software configuration management practices that allow pieces of code to be worked on in isolation from the rest, then later, merged back into the whole. The process of merging involves some extra work and added risk because it can introduce new bugs, but the added productivity of working in the branch often outweighs the extra costs.
There are several commonly used branching strategies. The choice can be determined by the requirements of the project or the workflow preferences of the team. Branches can correspond to phases of development, specific tasks, or particular releases.
Chris Birmele of Microsoft Australia recommends validating your chosen strategy by considering what would happen in a change scenario - would you have to completely restructure your branches to compensate? Try to predict the worst case and plan for it.
A commonly used branching strategy is one that corresponds to the three phases of development activity: Development, Test and Production. For in-depth discussions of branching strategies, see Microsoft Team Foundation Server Branching Guidance: [LINK] or PDF ( license)
26
Code Promotion branches: Branches associated with phases of development.
(from [LINK])
Branching by Release:
(from [LINK])
Branching by Task:
(from [LINK])
Whichever configuration you choose it's imperative that all team members are on board and fully understand the workflow and best practices associated with tagging, merging, etc. Symptoms of problems with team member's comprehension of the strategy, or of having chosen the wrong structure include avoidance of merging, deferring merges until the very end of the project and general confusion about versions. A longer list of "symptoms" can be seen here [LINK]
27
The branching structure used in the following tutorial is a task-based branch, where the branch is used for work on a specific tasks. These are short-term branches which are merged back into the main line of development - the Trunk - as soon as the task is completed.
Resources Team Foundation Server Branching Guidance MSDN: Branching and Merging Primer by Chris Birmele
28
Beginning Eclipse CVS - Branching Tutorial 2: Create the Project
NOTE: This section of the Eclipse CVS tutorial is based on Paul Glezen's article on the Eclipse website: Branching with Eclipse and CVS, and is used with his permission under the terms of the EPL license. The changes I am making to his version are mainly to expand it with more step by step images and explanations, and integrate it with my own beginner tutorials in an attempt to make it more accessible to beginners and designers. Experienced developers will probably prefer to work from Paul's version.
Download this zip archive: brtest.zip
The files contained in this archive refer to the two developers in this tutorial's "team," Paul and Wing. Decide who will be Paul and who will be Wing. If you are the only person who will be participating, you can play both. Additional people can be additional "Wings."
Some definitions The Workbench is the the complete set of windows and tools provided by
Eclipse. A Workspace is a folder containing your projects and resources. Each workspace
can have settings associated with it which control the workbench layout and behavior. You can have multiple workspaces - for example if you want to synchronize multiple servers to CVS all from your desktop, you can synch them using a workspace located on each server.
A Project is a set of resources, folders and files. The Project Explorer view provides a tree-structure display of all the resources in the Workspace.
In this tutorial, we'll create a new empty workspace, add a new project to it, andshare the project to CVS so that others can collaborate on it.
At this point the project will be tagged as a milestone and branched, so that two developers can work on different tasks. The discreet lines of code will then bemerged together and any conflicts resolved. After tagging again, and further work, a second merge will be performed.
Create a new workspace in a new, empty folder.
1. Launch Eclipse. It asks you to select a workspace. Click Browse...
29
2. Choose a location and create a new folder.
3. Select the folder you created and click "Choose".
30
4. The browse dialog closes. Click the OK button.
5. You should see the Welcome screen. Click Open Workbench. This would be a good time to set up your perspectives. If you aren't sure how to do this, Click here, then return back to this tutorial when you are done. Then select the ResourcePerspective.
31
Create a project in the new workspace
1. Create a new project by right-clicking inside the Project Explorer View (Left pane)
32
2. Choose General > Project.
3. Call it brtest and click Finish. A folder called brtest will appear in the Project Explorer view.
33
4. Right-click on the new brtest folder, and select Import. Select General > Archive File. Click Next.
34
5. Click Browse... then navigate to brtest.zip. The "Into folder" setting should already be set to your project folder. Click Finish.
35
6. You will be returned to the main window. If you open the project folder, you should now see four text files there.
36
Beginning Eclipse CVS - Branching Tutorial 3: Share the Project
NOTE: This section of the Eclipse CVS tutorial is based on Paul Glezen's article on the Eclipse website: Branching with Eclipse and CVS, and is used with his permission under the terms of the EPL license. The changes I am making to his version are mainly to expand it with more step by step images and explanations, and integrate it with my own beginner tutorials in an attempt to make it more accessible to beginners and designers. Experienced developers will probably prefer to work from Paul's version.
Now that you've created a new project, check it into the CVS repository so your team can collaborate on it.
1. Right-click the brtest project folder and select Team > Share Project.
2. Enter the login information for your CVS repository and click OK.
37
3. Leave it set to "Use project name as module name". Click Next.
38
4. It will ask you to review and commit the new resources. Committing a resource stores it in the CVS repository where it is visible to the rest of the team. You can also commit resources from the Team > Commit menu (available when you right-click on an item) or in the Synchronize view.
5. Add a comment to the comment area and click Finish. It will confirm that the resources are in sync. Click Finish again.
39
6. The name of the repository will now appear after the project folder name.
40
NOTE: This section of the Eclipse CVS tutorial is based on Paul Glezen's article on the Eclipse website: Branching with Eclipse and CVS, and is used with his permission under the terms of the EPL license. The changes I am making to his version are mainly to expand it with more step by step images and explanations, and integrate it with my own beginner tutorials in an attempt to make it more accessible to beginners and designers. Experienced developers will probably prefer to work from Paul's version.
41
Beginning Eclipse CVS - Branching Tutorial 4: Create a branch
NOTE: This section of the Eclipse CVS tutorial is based on Paul Glezen's article on the Eclipse website: Branching with Eclipse and CVS, and is used with his permission under the terms of the EPL license. The changes I am making to his version are mainly to expand it with more step by step images and explanations, and integrate it with my own beginner tutorials in an attempt to make it more accessible to beginners and designers. Experienced developers will probably prefer to work from Paul's version.
Now that you have created a project, the other people on your team should check it out from CVS. If they aren't sure how to check out a project from CVS, have them
Scenario walkthrough
We'll be following the workflow shown in the diagram below. This article will employ a scenario of two programmers, Paul and Wing, working on separate branches of the same project.
The main branch of development, or trunk, is labeled WD in the diagrams, because Wing will be developing in that branch. Paul first branches off main and modifies some files. His new branch is called p1test. He starts working in that branch.
At the same time, Wing is developing in the main branch. When she reaches a milestone, she commits the changes and tags them as W1.
42
When Paul reaches a development milestone, he commits his code changes to CVS and tags them as P1.
Then he switches to the main branch and merges the code from the p1test branch down into the main branch, fixing any conflicts that have arisen.
Note: Merges are performed INTO the branch you are currently working in, not FROM the branch you are working in.
Paul's tagged milestones give CVS a point of reference to determine what has changed since the milestone. Tags can also be used to denote stable versions or recovery points.
Now development continues. Paul opens the p1test branch again and continues working. When he reaches another milestone, he commits his changed files and tags them as P2.
At this point, Wing, working in the main branch, merges Paul's changes back down to the main branch, and resolves the conflicts. This scenario can be repeated as changes are made until work in the branch is completed and the final merge is done.
So let's get started with whoever is playing Paul:
43
1. Right-click the brtest project folder and select Team > Branch.
2. Call the new branch p1test. Make sure Start working in the branch is checked and click OK.
Eclipse will fill in a starting tag (Version Name) based on the branch name you choose: Root_p1test
44
We are now at this point in the workflow diagram.
The starting tag Root_p1test is a point of reference that will be used by Eclipse during the merging process to determine what has changed since the last time the code branches were identical.
When the branch is first created, the branch and trunk are identical. As work proceeds in both paths, differences arise between the two lines of code. At various points in development the branch and trunk are resynched together. Logical points for merges down to the main branch can be when new features in the branch reach a stable enough point for testing, or if the branch is still unstable, but a lot of work has occurred down in the trunk, the latest version of the trunk should be periodically merged up to the branch so that the branch does not fall too far out of synch with the main trunk.
If you wait too long to merge while parallel development occurs, it is possible to have problems with enormous code conflicts which need to be resolved. Merging is more of an art than a science, and it can take a fair
45
bit of thought and debugging to make things work right during a big merge. See Branching and Merging Anti-Patterns for information on "Big Bang Merges."
3. If you forgot to click Start working in the branch, right-click the project folder again, and select Switch to another branch or version, then select the p1testbranch and click Finish. You can tell what branch you are working in, if any, by looking at the name of the project folder. The branch name will be listed to the right of the project folder name.
46
Beginning Eclipse CVS - Branching Tutorial 5: Work in the branch
NOTE: This section of the Eclipse CVS tutorial is based on Paul Glezen's article on the Eclipse website: Branching with Eclipse and CVS, and is used with his permission under the terms of the EPL license. The changes I am making to his version are mainly to expand it with more step by step images and explanations, and integrate it with my own beginner tutorials in an attempt to make it more accessible to beginners and designers. Experienced developers will probably prefer to work from Paul's version.
1. Paul is working in the branch p1test. Open f1.txt in the text editor (Double-click f1.txt or right click it and select Open in Text Editor).
47
2. If line numbers are not showing in the text editor, turn them on by right-clicking in the middle of a text editor view. Select Preferences...
48
3. Check "Click show line numbers."
4. Change line 3 of f1.txt to read "This line changed by Paul in iter1. " and save the change.
5. Note that the file now shows a ">" indicator in Project Explorer, showing that it is no longer the same as the version in the repository. Open f3trivial.txt in the text editor. Change line 3 to read "This line changed by Paul in iter1." and save the change.
49
6. Open f4conflict.txt in the text editor. Change line 3 from "This line will be changed by both Paul and Wing" to "This line changed by Paul in iter1."and save the change.
7. Click the Synchronize icon, or right-click the brtest project folder and select Team > Synchronize with Repository. The Synchronize perspective will open and replace the Project Explorer. Commit all the changes by right-clicking the folder and selecting Team>Commit.
50
8. Type a comment like "First iteration changes made by Paul."
The version number will be a four-digit number like 1.1.2.1: the 2 represents the branch number.
9. The Synchronize perspective will now be empty, indicating that nothing remains out-of-synch. The repository's image of the branch is now identical to what is in your local workspace.
51
Click the Resource tab to return to the Project Explorer.
10.Since this is Paul's first round of changes in this branch he will tag this milestone asP1. Right click the project folder and select Team>Tag as Version.
52
11.Type P1 and click OK.
53
We are now at this point in the workflow diagram:
Beginning Eclipse CVS - Branching: Work continues in the Trunk
Option 1: If a second person is playing Wing, start at this step Option 2: If you are playing both Paul AND Wing, start at this step.
1. Option 1: A second person is playing Wing. You ("Wing") are starting fresh, so you will need to import the HEAD files into a new, empty workspace. Right-click in the white area in the Project Explorer, and select Import.
54
2. Select CVS >Projects from CVS and click Next.
55
3. Select the CVS repository you want to use from the list and click Next.
56
4. It will ask you to choose a workspace. If you do not already have a workspace directory to use, you can create one now.
57
5. Check the project out as brtest, selecting Checkout subfolders and click Next.
58
6. Select HEAD from the list of tags. Click Finish. Now go to your next step and continue
59
7. Option 2 starts here: If you started as "Paul" you already have a workspace with a project in it. Replace the files in your workspace with those of the HEAD by selectingTeam > Switch to Another Branch or Version. This replaces the resources in your workspace with those on the tag you specify in the next step.
60
8. Select HEAD from the list of tags. Click Finish.
9. You should now see a new brtest folder in your Project Explorer. There will be no branch listed to the right of the folder name, indicating that you are NOT working in a branch with respect to this project.
62
10.Now we'll start editing files as "Wing." First we'll edit a file that will only be edited by Wing. Open f2.txt. (The file f1.text is only going to be edited by Paul)
63
11.Change line 3 to read "This line changed by Wing in iter1." Save the change. A ">" will be added beside f2.txt
12.Open f3trivial.txt. This file will be edited by both Paul and Wing, but on separate lines, only. Change line 9 to "This line changed by Wing in iter1." Save the change.
13.Open f4conflict.txt. This file will be edited by both Paul and Wing on the same line. Change line 3 to "This line changed by Wing in iter1." Save the file.
64
14.Commit all these changes. Right-click the project folder and select Team > Commit
65
15.Add a comment: "First iteration changes by Wing."
16.The version numbers will remain 2 digit numbers because the changes were made on the trunk.
66
17.Right-click the brtest folder and select Team > Tag as Version...
18.Enter the name W1.
67
We're now here in the flowchart:
68
Beginning Eclipse CVS - Branching: Merge changes back to the Trunk
When last we left Paul, he was working in the branch p1test. Now he is going to close his branch, open the Trunk and merge his changed files down to the Trunk. If you were playing Paul before, you may still have his branch open. If not, skip to this step.
1. Expand the folder containing this branch. The changes Paul made in this folder have all been committed to CVS under the branch so they are completely backed up. So we can replace them with the Trunk version of the files and start merging Paul's changes back in to the Trunk.
2. Right-click the folder containing p1test and select Replace with Another Branch or Version...
69
3. Select HEAD and click OK.
4. The branch name should no longer appear to the right of the project name.
5. You are now working in the Trunk. Right-click on the project folder and selectTeam>Merge....
70
6. Click Browse next to Branch or version to be merged. Choose p1test.
71
7. It will try to guess the common base version for you. In this case it will guess correctly: Root_p1test. It will use the file versions tagged with Root_p1test to determine what has changed since then. So you can see why it is important to tag your files at milestones - it is one way to have control over exactly what gets merged. You can restrict merges to specific intervals, keeping them as small as necessary, and not have to re-merge old changes.
Leave Merge non-conflicting changes and only preview conflicts unchecked. ClickFinish.
8. It will now ask you to Synchronize. Files which have been changed by Paul in the branch since Root_p1test will display different arrow icons depending on whether they conflict or not with the changes Wing has made in the Trunk. Blue arrows meannon-conflicting changes; red arrows indicate conflicts.
Take a look at the buttons available in Synchronize mode. The blue and red arrow buttons are filters. Clicking the blue-arrow button will show incoming changes. Clicking the red arrow will show only the conflicts. For more on the Merge Synchronization view, see this page
Merge non-conflicting changes and only preview conflicts"
72
when we selected merge points. Click OK.
9. You'll see the remaining conflicting file in the Synchronize View. To resolve the conflicts, double-click f4conflict.txt to open the Compare editor of the merge tool.
10.Line 3 of the local file (on the left) will say "This line changed by Wing in iter1." Line 3 of the remote (repository) file will say "This line changed by Paul in iter 1." Resolve the conflict by changing Line 3 of the Local file to "This line changed
73
by Paul and Wing in iter 1." Right-click in the Local side, and select Save.
Since this was not a trivial merge, the color red was used to display the areas that need work. Blue would be used to denote trival merges. Resolving code conflicts can take some thought - that's why CVS is asking for human help.
11.Even after the save, the entry in the conflict editor and the red arrow icon will remain red. This is because, as far as Eclipse knows, there is still a conflict, albeit with some extra changes. To inform Eclipse that the conflict is resolved, right-click the file in the Synchronize view and select Mark as Merged.
74
12.At this point, the merged version only exists in the local workspace. Commit it to the CVS repository by right-clicking the brtest project folder in the Project Explorerview, and select Team > Synchronize with Repository.
75
13.These changes should not present any conflicts: all the arrows are gray, indicating simple one-way changes. Right-click on the brtest folder again, and select Commit...
76
14.Add a comment as shown.
15.Tag the result as WM1: Right click the brtest folder, select Team >Tag as Version
78
16.Enter the tag WM1
17.You may view and select from existing tags by clicking Details>>. After the tag you just created, the list should look like this.
79
18.At this point, we are here in the scenario diagram:
19.To review what we've accomplished so far, let's look at the History panel. Right-clickf4conflict.txt in the Project Explorer and select Team > Show History.
80
20.We can see that the Root_p1test tag is assigned to revision 1.1, the initial version. This means "Branch 1, version 1). Branch 1 is the main branch or Trunk.
Paul's change ("First iteration changes made by Paul") were assigned to revision 1.1.2.1, or Branch 2, version 1 of the main branch, version 1.1. Wing made changes that were committed to the main branch. Finally, the merge resulted in revision 1.3, which was tagged for posterity with the label WM1.
81