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
CVS
7. 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:

Right click on the left window. Select New : Repository Location from the menu that appears.

4
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
9. Review and commit the resources (in this case, just a folder and a project file) to the repository.

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
17
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 bit of thought and debugging

45
 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).

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...

47
3. Check "Click show line numbers."

48
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.

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

49
 Project Explorer. Commit all the changes by right-clicking the folder and
selecting Team>Commit.

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.

50
 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.

51
11. Type P1 and click OK.

52
 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.

53
2. Select CVS >Projects from CVS and click Next.

54
3. Select the CVS repository you want to use from the list and click Next.

55
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.

56
5. Check the project out as brtest, selecting Checkout subfolders and click Next.

57
6. Select HEAD from the list of tags. Click Finish. Now go to your next step and continue

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.

58
59
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.

60
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)

61
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.

62
14. Commit all these changes. Right-click the project folder and select Team > Commit

63
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.

64
17. Right-click the brtest folder and select Team > Tag as Version...

18. Enter the name W1.

65
We're now here in the flowchart:

66
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...

67
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....

68
6. Click Browse next to Branch or version to be merged. Choose p1test.

69
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" when we

selected merge points. Click OK.

70
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 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

71
 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.

72
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.

73
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...

74
75
14. Add a comment as shown.

76
15. Tag the result as WM1: Right click the brtest folder, select Team >Tag as Version

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.

77
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.

78
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.

79