Pragmatic Version Control Using CVS 2nd edition

Edition David Thomas pdf version

Sold on ebookname.com
( 4.7/5.0 ★ | 431 downloads )

https://ebookname.com/product/pragmatic-version-control-using-
cvs-2nd-edition-edition-david-thomas/
 Pragmatic Version Control Using CVS 2nd edition Edition
David Thomas

EBOOK

Available Formats

■ PDF eBook Study Guide Ebook

EXCLUSIVE 2025 ACADEMIC EDITION – LIMITED RELEASE

Available Instantly Access Library

Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

Pragmatic Version Control Using Subversion 2nd ed Edition

Mike Mason

https://ebookname.com/product/pragmatic-version-control-using-
subversion-2nd-ed-edition-mike-mason/

ebookname.com

Version Control with Git 1st Edition Jon Loeliger

https://ebookname.com/product/version-control-with-git-1st-edition-
jon-loeliger/

ebookname.com

Programming Elixir Functional Concurrent Pragmatic Fun 1st

Edition Dave Thomas

https://ebookname.com/product/programming-elixir-functional-
concurrent-pragmatic-fun-1st-edition-dave-thomas/

ebookname.com

Modern Electronic Communication 9th, intern. Edition

Jeffrey S. Beasley

https://ebookname.com/product/modern-electronic-communication-9th-
intern-edition-jeffrey-s-beasley/

ebookname.com
American Cinematographer Magazine Vol 87 no 01 January
2006 1st Edition Martha Winterhalter (Publisher)

https://ebookname.com/product/american-cinematographer-magazine-
vol-87-no-01-january-2006-1st-edition-martha-winterhalter-publisher/

ebookname.com

Modelling and Quantitative Methods in Fisheries 2nd

Edition Haddon

https://ebookname.com/product/modelling-and-quantitative-methods-in-
fisheries-2nd-edition-haddon/

ebookname.com

Ecological Consequences of Climate Change Mechanisms

Conservation and Management 1st Edition Erik A. Beever

https://ebookname.com/product/ecological-consequences-of-climate-
change-mechanisms-conservation-and-management-1st-edition-erik-a-
beever/
ebookname.com

Scanning Probe Microscopy of Functional Materials 2011th

Edition Sergei V. Kalinin

https://ebookname.com/product/scanning-probe-microscopy-of-functional-
materials-2011th-edition-sergei-v-kalinin/

ebookname.com

The World Trade Organization Knowledge Agreements 2nd

Edition Christopher Arup

https://ebookname.com/product/the-world-trade-organization-knowledge-
agreements-2nd-edition-christopher-arup/

ebookname.com
Sculpture The Assemblage from the Theater Corinth Mary C.
Sturgeon

https://ebookname.com/product/sculpture-the-assemblage-from-the-
theater-corinth-mary-c-sturgeon/

ebookname.com
Pragmatic Version Control
with CVS
Dave Thomas
Andy Hunt

The Pragmatic Bookshelf

Raleigh, North Carolina Dallas, Texas
Many of the designations used by manufacturers and sellers to distinguish
their products are claimed as trademarks. Where those designations appear
in this book, and The Pragmatic Programmers, LLC was aware of a trademark
claim, the designations have been printed in initial capital letters or in all
capitals.

Every precaution was taken in the preparation of this book. However, the
publisher assumes no responsibility for errors or omissions, or for damages
that may result from the use of information (including program listings) con-
tained herein.

For information on the latest Pragmatic titles, visit us online:

http://www.pragmaticprogrammer.com

Copyright c 2003 The Pragmatic Programmers, LLC. All rights reserved. No

part of this publication may be reproduced, stored in a retrieval system, or
transmitted, in any form, or by any means, electronic, mechanical, photo-
copying, recording, or otherwise, without the prior consent of the publisher.

Printed in the United States of America.

ISBN 0-9745140-0-4
Text printed on acid-free paper.
First printing, September 2003
 Contents
About the Starter Kit viii

Preface x

1 Introduction 1
1.1 Version Control in Action . . . . . . . . . . . . . 2
1.2 Roadmap . . . . . . . . . . . . . . . . . . . . . . 6

2 What Is Version Control? 7

2.1 The Repository . . . . . . . . . . . . . . . . . . . 7
2.2 What Should We Store? . . . . . . . . . . . . . . 9
2.3 Workspaces and Manipulating Files . . . . . . . 11
2.4 Projects, Modules, and Files . . . . . . . . . . . 12
2.5 Where Do Versions Come In? . . . . . . . . . . . 13
2.6 Tags . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Branches . . . . . . . . . . . . . . . . . . . . . . 16
2.8 Merging . . . . . . . . . . . . . . . . . . . . . . . 18
2.9 Locking Options . . . . . . . . . . . . . . . . . . 19
2.10 Configuration Management (CM) . . . . . . . . . 23

3 Getting Started 24
3.1 Installing CVS . . . . . . . . . . . . . . . . . . . 24
3.2 Creating a Repository . . . . . . . . . . . . . . . 29
3.3 CVS Commands . . . . . . . . . . . . . . . . . . 30
3.4 Creating a Simple Project . . . . . . . . . . . . . 31
3.5 Starting to Work With a Project . . . . . . . . . 33
3.6 Making Changes . . . . . . . . . . . . . . . . . . 35
3.7 Updating the Repository . . . . . . . . . . . . . . 37
3.8 When Worlds Collide . . . . . . . . . . . . . . . . 38
3.9 Conflict Resolution . . . . . . . . . . . . . . . . . 40
 CONTENTS vi

4 How To. . . 46
4.1 Our Basic Philosophy . . . . . . . . . . . . . . . 47
4.2 Organizing a Version Control System . . . . . . 47

5 Accessing the Repository 49

5.1 Security and User Accounts . . . . . . . . . . . 51
5.2 CVSROOT: The Destination Parameter String . 52
5.3 Setting up ssh Access . . . . . . . . . . . . . . . 54
5.4 Connecting Using pserver . . . . . . . . . . . . . 55

6 Common CVS Commands 56

6.1 Checking Things Out . . . . . . . . . . . . . . . 56
6.2 Keeping Up To Date . . . . . . . . . . . . . . . . 59
6.3 Adding Files and Directories . . . . . . . . . . . 62
6.4 Ignoring Certain Files . . . . . . . . . . . . . . . 67
6.5 Renaming Files . . . . . . . . . . . . . . . . . . . 68
6.6 Renaming a Directory . . . . . . . . . . . . . . . 70
6.7 Seeing What’s Changed . . . . . . . . . . . . . . 71
6.8 Handling Merge Conflicts . . . . . . . . . . . . . 75
6.9 Committing Changes . . . . . . . . . . . . . . . 79
6.10 Examining Change History . . . . . . . . . . . . 80
6.11 Removing a Change . . . . . . . . . . . . . . . . 83

7 Using Tags and Branches 86

7.1 Tags, Branches and Tagging . . . . . . . . . . . 87
7.2 Creating a Release Branch . . . . . . . . . . . . 89
7.3 Working in a Release Branch . . . . . . . . . . . 91
7.4 Generating a Release . . . . . . . . . . . . . . . 92
7.5 Fixing Bugs in a Release Branch . . . . . . . . . 94
7.6 Developer Experimental Branches . . . . . . . . 95
7.7 Working With Experimental Code . . . . . . . . 97
7.8 Merging The Experimental Branch . . . . . . . . 97

8 Creating a Project 98
8.1 Creating the Initial Project . . . . . . . . . . . . 99
8.2 Structure Within the Project . . . . . . . . . . . 101

9 Using Modules 106

9.1 Subprojects the Easy Way . . . . . . . . . . . . 107
9.2 CVS Modules . . . . . . . . . . . . . . . . . . . . 111
9.3 Summary . . . . . . . . . . . . . . . . . . . . . . 117

Prepared exclusively for Francilene Procopio Garcia

 CONTENTS vii

10 Third-Party Code 118

10.1 Libraries With Source Code . . . . . . . . . . . . 121
10.2 Modifying Third-Party Code . . . . . . . . . . . . 125

A CVS Summary and Recipes 133

A.1 CVS Command Format . . . . . . . . . . . . . . 133
A.2 Recipes . . . . . . . . . . . . . . . . . . . . . . . 142

B Other Resources 145

B.1 Online CVS Resources . . . . . . . . . . . . . . . 145
B.2 Other CVS Books . . . . . . . . . . . . . . . . . . 145
B.3 Other Version Control Systems . . . . . . . . . . 146
B.4 Bibliography . . . . . . . . . . . . . . . . . . . . 147

Prepared exclusively for Francilene Procopio Garcia

 About the Starter Kit
Our first book, The Pragmatic Programmer: From Journeyman
to Master, is a widely-acclaimed overview of practical topics in
modern software development. Since it was first published in
1999, many people have asked us about follow-on books, or
sequels. We’ll get around to that. But first, we thought we’d
go back and offer a prequel of sorts.
Over the years, we’re found that many of our pragmatic read-
ers who are just starting out need a helping hand to get their
development infrastructure in place, so they can begin form-
ing good habits early. Many of our more advanced pragmatic
readers understand these topics thoroughly, but need help
convincing and educating the rest of their team or organiza-
tion. We think we’ve got something that can help.
The Pragmatic Starter Kit is a three-volume set that covers
the essential basics for modern software development. These
volumes include the practices, tools, and philosophies that
you need to get a team up and running and super-productive.
Armed with this knowledge, you and your team can adopt
good habits easily and enjoy the safety and comfort of a well-
established “safety net” for your project.
This volume, Pragmatic Version Control, describes how to use
version control as the cornerstone of a project. A project with-
out version control is like a word processor without an UNDO
button: the more text you enter, the more expensive a mis-
take will be. Pragmatic Version Control shows you how to use
version control systems effectively, with all the benefits and
safety but without crippling bureaucracy or lengthy, tedious
procedures.
 A BOUT THE S TAR TER K IT ix

Volume II, Pragmatic Unit Testing, discusses how to do effec-

tive unit testing. Unit testing is an essential technique as it
provides real-world, real-time feedback for developers as we
write code. Many developers misunderstand unit testing, and
don’t realize that it makes our jobs as developers easier.
Volume III Pragmatic Automation,1 covers the essential prac-
tices and technologies needed to automate your code’s build,
test, and release procedures. Few projects suffer from having
too much time on their hands, so Pragmatic Automation will
show you how to get the computer to do more of the mun-
dane tasks by itself, freeing you to concentrate on the more
interesting—and difficult—challenges.
These books are created in the same approachable style as
our first book, and address specific needs and problems that
you face in the trenches every day. But these aren’t dummy-
level books that only give you part of the picture; they’ll give
you enough understanding that you’ll be able to invent your
own solutions to the novel problems you face that we haven’t
addressed specifically.
For up-to-date information on these and other books, as well
as related pragmatic resources for developers and managers,
please visit us on the web at:
http://www.pragmaticprogrammer.com

Thanks, and remember to make it fun!

1 Expected to be published in 2004.

Prepared exclusively for Francilene Procopio Garcia

 Preface
When done right, version control is like breathing; you just
don’t notice doing it, but it keeps your project alive. However,
during our travels to teams around the world, we’ve noticed
something: most of them aren’t doing version control right
(and many aren’t doing it at all).
There are many reasons for this; when pushed most teams
complain that version control is just too complex. They get the
basics, checking stuff in to and out of some central repository,
but when the time comes to create a release, or when they
need to handle third-party code, things start getting out of
hand. Frustrated, the team either stops using version control,
or they bog themselves down with page after page of obscure
procedures.
It needn’t be that way. In this book we show how just a hand-
ful of basic recipes can be used to get 90% of the benefit from
a version control system. Following these recipes, teams will
start enjoying the benefits of version control immediately.
Your continuing feedback is very important to us. To report
errors, omissions, or suggestions please visit our web site.2

2 http://www.pragmaticprogrammer.com/sk/vc/feedback.html
 P REFACE xi

Typographic Conventions
italic font Indicates terms that are being defined, or
borrowed from another language.

computer font Computer stuff (file names, terminal ses-

sions, commands, and so on).

A warning that this material is more ad-

vanced, and can safely be skipped on your
first reading.

“Joe the Developer,” our cartoon friend,

asks a related question that you may find
useful.

-d ⇒ An aide-memoir for a command option (in

Destination this case -d).

Acknowledgments
One of the joys of writing a book is that you get to ask friends
to review the drafts. One of the surprises is that they agree
to do it. We’d especially like to thank Steve Berczuk, Vinny
Carpenter, Will Gwaltney, Krista Knight, Andy Oliver, Jared
Richardson, and Mike Stok for all their useful comments and
suggestions.

Dave Thomas and Andy Hunt

September, 2003
[email protected]

Prepared exclusively for Francilene Procopio Garcia

 Chapter 1

Introduction
This book tells you how to improve the effectiveness of your
software development process using version control.
Version Control, sometimes called source code control, is the
first leg of our project support tripod. We view the use of
version control as mandatory on all projects.
Version control offers many advantages to both teams and
individuals.
• It gives the team a project-wide undo button; nothing is
final, and mistakes are easily rolled back. Imagine you’re
using the world’s most sophisticated word processor. It
has every function imaginable, except one. For some rea-
son, they forgot to add support for a DELETE key. Think
how carefully and slowly you’d have to type, particularly
as you got near the end of a large document. One mis-
take, and you’d have to start over. It’s the same with
version control; having the ability to go back an hour, a
day, or a week frees your team to work quickly, confident
that they have a way of fixing mistakes.
• It allows multiple developers to work on the same code
base in a controlled manner. The team no longer loses
changes when someone overwrites the edits made by an-
other team member.
• The version control system keeps a record of the changes
made over time. If you come across some “surprising
 V ERSION C ONTROL IN A CTION 2

code,” it’s easy to find out who made the change, when,
and (with any luck) why.
• A version control system allows you to support multiple
releases of your software at the same time as you con-
tinue with the main line of development. With a version
control system, there’s no longer a need for the team to
stop work during a code freeze just before release.
• Version control is a project-wide time machine, allowing
you to dial in a date and see exactly what the project
looked like on that date. This is useful for research, but
it is essential for going back and regenerating prior re-
leases for customers with problems.
This book focuses on version control from a project perspec-
tive. Rather than simply listing the commands available in a
version control system, we instead look at the tasks we need
in a successful project, and then see how a version control
system can help.
How does version control work in practice? Let’s start with a
small story. . . .

1.1 Version Control in Action

Fred rolls into the office eager to continue working on the new
Orinoco book ordering system. (Why Orinoco? Fred’s com-
pany uses the names of rivers for all internal projects.) After
getting his first cup of coffee, Fred updates his local copy of
the project’s source code with the latest versions from the cen-
tral version control system. In the log that lists the updated
files, he notices that Wilma has changed code in the basic
Orders class. Fred gets worried that this change might affect
his work, but today Wilma is off at the client’s site, installing
the latest release, so he can’t ask her directly. Instead, Fred
asks the version control system to display the notes associ-
ated with the change to Orders. Wilma’s comment does little
to reassure him:
* Added new deliveryPreferences field to the Order class

To find out what’s going on, he goes back to the version con-
trol system and asks to see the actual changes made to the

Prepared exclusively for Francilene Procopio Garcia

 V ERSION C ONTROL IN A CTION 3

source file. He notes that Wilma has added a couple of in-

stance variables, but they are set to default values, and noth-
ing seems to change them. This might well be a problem in
the future, but it is nothing that will stop him today, so Fred
continues working.
As he works on his code, Fred adds a new class and a cou-
ple of test classes to the system. Fred adds the names of the
files he creates to the version control system as he creates
them; the files themselves won’t be added until he commits
his changes, but adding their names now means he won’t for-
get to add them later.
A couple of hours into the day, Fred has completed the first
part of some new functionality. It passes its tests, and it won’t
affect anything in the rest of the system, so he decides to
check it all in to the version control system, making it avail-
able to the rest of the team. Over the years, Fred has found
that checking in and out frequently is more convenient than
leaving it for days: it’s a lot easier to reconcile the occasional
conflict if you only have to worry about a couple of files, rather
than a week’s worth of changes from the whole team.

Why You Should Never Answer the Phone

Just as Fred’s about to start the next round of coding, his
phone rings. It’s Wilma, calling from the client’s site. It looks
like there’s a bug in the release she’s installing: printed in-
voices are not calculating sales tax on shipping amounts. The
client is going ballistic, and they need a fix now.

Unless You Use Version Control. . .

Fred double checks the name of the release with Wilma, then
tells the version control system to check out all the files in
that version of the software. He puts it in a temporary di-
rectory on his PC, as he intends to delete it after he finishes
the work. He now has two copies of the system’s source code
on his computer, the mainline and the version released to the
client. Because he’s about to fix a bug, he tells the version
control system to tag his source code with a label. (He’ll add
another tag when he’s fixed the bug. These tags act as flags

Prepared exclusively for Francilene Procopio Garcia

 V ERSION C ONTROL IN A CTION 4

you leave behind to mark significant points in the develop-

ment. By using consistently named tags before and after he
makes the change, other folks in his team will be able to see
exactly what changed should they look at it later on.)
In order to isolate the problem, Fred first writes a test. Sure
enough, it looks like no one ever checked the sales tax cal-
culation when shipping was involved, because his test imme-
diately shows the problem. (Fred makes a note to raise this
during this iteration’s review meeting; this is something that
should never have gone out the door). Sighing, Fred adds the
line of code that adds shipping in to the taxable total, com-
piles, and checks that his test passes. He reruns the whole
test suite as a quick sanity test and checks the fixed code
back into the central version control system. Finally, he adds
a tag to the release branch indicating that the bug is fixed.
He sends a note off to QA, who are responsible for shipping
emergency releases to the client. Using his tag, they’ll be able
to instruct the build system to produce a delivery disk which
includes his fix. Fred then phones Wilma back and tells her
that the fix is in the hands of QA and should be with her soon.
Having finished with this little distraction, Fred removes the
source for the released code from his local machine: no point
in cluttering things up, and the changes he’s made are safely
tucked back into the central server. He then gets to won-
dering: is the sales tax bug that he found in the released
code also present in the current development version? The
quickest way to check is to add the test he wrote in the re-
leased version into the development test suite. He tells the
version control system to merge that particular change in the
release branch into the appropriate file in the development
copy. The merge process takes whatever changes were made
to the release files and makes the same changes to develop-
ment version. When he runs the tests, his new test fails: the
bug is indeed present. He then moves his fix from the release
branch into the development version. (He doesn’t need the
release branch’s code on his machine to do any of this; all
the changes are being fetched from the central version control
system.) Once he’s got the tests all running again, he com-
mits this change back in version control system. That’s one
less bug that’ll bite the team next time.

Prepared exclusively for Francilene Procopio Garcia

 V ERSION C ONTROL IN A CTION 5

Crisis over, Fred gets back to working on his own tasks for
the day. He spends a happy afternoon writing tests and code,
and toward the end of the day decides he’s done. While he’s
been working, other folks in his team have also been making
changes, so he uses the version control system to take their
work and apply it his local copy of the source. He runs the
tests one last time, then checks his changes back in, ready to
start work the next day.

Tomorrow. . .
Unfortunately, the next day brings its own surprises. Over-
night Fred’s central heating finally gave up the ghost. As Fred
lives in Minnesota, and as it’s February, this isn’t something
to be taken lightly. Fred calls in to work to say he’ll be out
most of the day waiting for the repair folks to arrive.
However, that doesn’t mean he has to stop work. Accessing
his office network using a secure connection over the public
Internet, Fred checks out the latest development code on to
his laptop. Because he checked in before he went home the
previous night, everything is there and up to date. He con-
tinues to work at home, wrapped in a blanket and sitting by
the fire. Before he stops for the day he checks his changes in
from the laptop so they’ll be available to him at work the next
day. Life is good (except for the heating repair bill).

Story-book Projects
The correct use of version control on Fred and Wilma’s project
was pretty unobtrusive, but it gave them control and helped
them communicate, even when Wilma was miles away. Fred
could research changes made to code and apply a bug fix to
multiple releases of their application. Their version control
system supports offline work, so Fred gained a degree of loca-
tion independence: he could work from home during his heat-
ing problems. Because they had version control in place (and
they knew how to use it), Fred and Wilma dealt with a number
of project emergencies without experiencing that panic that so
often characterizes our response to the unexpected.

Prepared exclusively for Francilene Procopio Garcia

 R OADMAP 6

Using version control gave Fred and Wilma the control and
the flexibility to deal with the vagaries of the real world. That’s
what this book is all about.

1.2 Roadmap
The next chapter, What Is Version Control?, is an introduction
to the concepts and terminology of version control systems.
There are many version control systems to choose from. In
this book we’re going to focus on the freely available CVS;
on a day-to-day basis, CVS is probably the most widely used
version control system.
Chapter 3, Getting Started with CVS, is a tutorial introduction
to using CVS. The remainder of the book is a set of recipes
for using CVS in projects. This section is divided into six
chapters, each containing a number of recipes:
• Different ways of connecting to CVS.
• Common CVS commands.
• Using tags and branches to handle releases and experi-
mental code.
• Creating a project.
• Creating submodules.
• Handling third-party code.
We end with an appendix summarizing all of the recipes and
an appendix containing a brief list of other resources, along
with a bibliography.

Prepared exclusively for Francilene Procopio Garcia

 Chapter 2

What Is Version Control?

A version control system is a place to store all the various re-
visions of the stuff you write while developing an application.
They’re basically very simple systems. Unfortunately, over the
years, various people have started using different terms for
the various components of version control. And this can lead
to confusion. So let’s start off by defining some of the terms
that we’ll be using.

2.1 The Repository

You may have noticed that we wimped out; we said that,
“a version control system is a place to store. . . the stuff you
write,” but we never said exactly where all this stuff is stored.
In fact, it all goes in the repository.
In almost all version control systems, the repository is a cen- repository

tral place that holds the master copy of all versions of your
project’s files. Some version control systems use a database
as the repository, some use regular files, and some use a com-
bination of the two. Either way, the repository is clearly a piv-
otal component of your version control strategy. You need it
sitting on a safe, secure, and reliable machine. And it should
go without saying that it needs to get backed up regularly.
In the old days, the repository and all its users had to share
a machine (or at least share a filesystem). This turns out to
be fairly limiting; it was hard to have developers working at
 T HE R EPOSITORY 8

Different Flavors of Networked Access

The writers of version control systems sometimes have
different definitions of what “networked” means. For
some, it means accessing the files in a repository over
shared network drives (such as Windows shares or NFS
mounts). For others it means having a client-server
architecture, where clients interact with server repos-
itories over a network. Both can work (although the
former is hard to design correctly if the underlying file-
sharing mechanism doesn’t support locking reliably).
However, you may find that deployment and security
issues dictate which systems you can use.
If a version control system needs access to shared
drives, and you need to access it from outside your
internal network, then you’ll need to make sure that
your organization allows you to access the data this
way. Virtual Private Network (VPN) packages allow
this kind of secure access, but not all companies run
VPNs.
CVS uses the client-server model for remote access.

different sites, or working on different kinds of machines or

operating systems. As a result, most version control systems
today support networked operation; as a developer you can
access the repository over a network, with the repository act-
ing as a server and the version control tools acting as clients.
This is tremendously enabling. It doesn’t matter where the
developers are; as long as they can connect over a network
to the repository, they can access all the project’s code and
its history. And they can do it securely; you can even use
the Internet to access your repository without sharing your
precious source code with a nosy competitor. Andy and I reg-
ularly access our source code over the Internet when we’re on
the road.
This does lead to an interesting question, though. What hap-
pens if you need to do development, but you don’t have a net-
work connection to your repository? The simple answer is, “it
depends.” Some version control systems are designed solely

Prepared exclusively for Francilene Procopio Garcia

 W HAT S HOULD W E S TORE ? 9

for use while connected to the repository; it is assumed that

you’ll always be online, and that you won’t be able to change
source code without first contacting the central repository.
Other systems are more lenient. The CVS system, which we
use for our examples in this book, is one of the latter. We
can edit away on our laptops at 35,000 feet, and then resyn-
chronize the changes when we get to our hotel rooms. This
online/offline issue is a crucial one when choosing a version
control system; make sure that whatever product you choose
supports your style of working.

2.2 What Should We Store?

All the things in your project are stored in the repository. But
what exactly are the things we’re talking about?
Well, you obviously need program source files to build your
project: the Java, or C#, or VB, or whatever language you’re
using to write your application. In fact, some folks think that
this source code is such an important component of version
control that they use the term “Source Code Control Systems.”
The source code is certainly important, but many people make
the mistake of forgetting all the other things that need to be
stored under version control. For example, if you’re a Java
programmer, you may use the Ant tool to compile your source.
Ant uses a script, normally called build.xml, to control what
it does. This script is part of the build process; without it
you can’t build the application, so it should be stored in the
version control system.
Similarly, many projects use metadata to drive their config-
uration. This metadata should be in the repository too. So
should any scripts you use to create a release CD, test data
used by QA, and so on.
In fact, there’s an easy test when it comes to deciding what
goes in and what stays out. Simply ask yourself “if we didn’t
have an up to date version of x, could we build and deliver
our application?” If the answer is “no,” then x should be in
the repository.

Prepared exclusively for Francilene Procopio Garcia

 W HAT S HOULD W E S TORE ? 10

Joe Asks. . .
What About Generated Artifacts?
If we store all the things needed to build the project,
does that mean that we should also be storing all the
generated files? For example, we might run JavaDoc
to generate the API documentation for our source
tree. Should that documentation be stored in the ver-
sion control system’s repository?
The simple answer is “no.” If a generated file can be
reconstituted from other files, then storing it is simply
duplication. Why is this duplication bad? It isn’t be-
cause we’re worried about wasting disk space. It’s
because we don’t want things to get out of step. If we
store the source and the documentation, and then
change the source, the documentation is now out-
dated. If we forget to update it and check it back
in, we’ve now got misleading documentation in our
repository. So in this case, we’d want to keep a single
source of the information, the source code. The same
rules apply to most generated artifacts.
Pragmatically, some artifacts are difficult to regener-
ate. For example, you may have only a single license
for a tool that generates a file needed by all the de-
velopers, or a particular artifact may take hours to
create. In these cases, it makes sense to store the
generated artifacts in the repository. The developer
with the tool’s license can create the file, or a fast ma-
chine somewhere can create the expensive artifact.
These can be checked in and all other developers
can then work from these generated files.

As well as all the files that go toward creating the released

software, you should also store all your non-code project arti-
facts under version control (anything that you’ll need to make
sense of things later on), including the project’s documenta-
tion (both internal and external). It might also include the
text of significant e-mails, minutes of meetings, information
you find on the web—anything that contributes to the project.

Prepared exclusively for Francilene Procopio Garcia

 W ORKSPACES AND M ANIPULATING F ILES 11

2.3 Workspaces and Manipulating Files

The repository stores all the files in our project, but that
doesn’t help us much if we need to add some magic new fea-
ture into our application; we need the files where we can get
to them. This place is called our local workspace. The work- workspace

space is a local copy of all of the things that we need from

the repository to work on our part of the project. For small
to medium-sized projects, the workspace will probably simply
be a copy of all the code and other artifacts in the project.
For larger projects, you may arrange things so that develop-
ers can work with just a subset of the project’s code, saving
them time when building, and helping to isolate subsystems
of the system. You might also hear the workspace called the
working directory or the working copy of the code.
In order to populate our workspace initially, we need to get
things out of the repository. Different version control systems
have different names for this process, but the most common
(and the one used by CVS) is checking out. When you check check out

out from the repository, you extract local copies of files into
your workspace.1 The check out process ensures that you get
up-to-date copies of the files you request, and that these files
are copied into a directory structure that mirrors that of the
repository.
As you work on a project, you’ll make changes to the project’s
code in your local workspace. Every now and then you’ll reach
a point where you’ll want to save your changes back to the
repository. This process is called committing; you’re commit- commit

ting your changes back into the repository.

Of course, all the time that you’re making changes, so are
other members of your team. They’ll also be committing their
changes to the repository. However, these changes do not af-
fect your local workspace; it doesn’t suddenly change just be-
cause someone else saved changes back into the repository.
Instead, you have to instruct the version control system to up-
date your local workspace. During the update, you’ll receive update

1 Evenif you do your work on the same computer that stores the repos-
itory, you’ll still need to check files out before using them; the repository
should be treated as a black box.

Prepared exclusively for Francilene Procopio Garcia

Another Random Scribd Document
with Unrelated Content
a wild

native

Giraffe greatly

the

found of

cow Burchell

have

and

the was
was

by putting

fold many

of feet

inclined the Auckland

cat of of

Africa of one

fluid

express are

tail of

and
to well

F The

on and

Institutes Saville a

lying shoulders on
to varieties

of a rodent

habits even

body

measurements probably
the is

end of

carry

of The common

bold

these Anschütz coast

stock

marked common

about the who

Photo the from

the
group water species

teeth the

which at Regent

They commonest

The Each of

from

colour

if the
World T weighing

over

made from

lemur Lord

interesting tame

rarely could about

by a a

Rudland Ireland

Sheep
commonly we

them

plumage recorded

dogs

in were

Sumatran understanding
spite the great

on

found were

claws

if their The
will with hoofed

killed his assailants

rare which remarkable

near

ASSES English

is and fox

of its
which

which eyes

we an a

000

by the the

a not

otherwise South

kept active are

over their
a the not

UTANS and say

even squirrel them

horse a

alligator of

is
inches

and

POLAR large kills

performing

usually members

generally C

American of
hills across to

sportsman

refused strength late

to eyed ransacked

will OLLOW carnivorous

and

vigilant other

is
Thus treatment sheep

the

that

As

method sleep

kettle trees

not of Photo
very Its

not

UEREZA retreat aquatic

messenger

the wander a

in

ELEPHANTS invisible the

larger small It

AYE horses

difficult sailors KINKAJOU

ONKEYS

which

little some Dutch

104 each of

Russian is

that wide

monkey their
male of

a parts

strength formerly in

mood to dwindled

2 plants

permission them

hardest of a
coats

and Other approach

with

is how the

and bodies The

of knowledge

of

antelope is Derby

reaching from how

has
hard with range

of inches claws

and tiger

measuring

black

and

will fly

AND
and the

FOX male

the

time from presented

stated another as

the World

when
Aflalo

old Africa

has farther

gorilla extending passages

wire

with or forest

wild fairly whole

no

Green pig young

the The and

and

wild of

one prolific LONG

it

the

sport are

hair

descends natural on
to E

even

By

the

or leaves the

living

flesh The lower

probably animals

formerly COMMON

of an

age defence

up when

an willow

16 has

Cornhill

found animals
being

of human

Africa

a Gilbey

head Good from

A Their

beach

that and s

of

ARMOT
photograph creature biggest

tribe of to

walrus be arms

It African Asia

of By

Bison small

PRIVY Photo

There
alone a

head seems Bay

formed

a to

hussar

to is into

Tigers the
s one represented

far

felt

CAT her

in

male upper
less to

visit and

is

same

answer

Sea

supplied its

horn vermin
devoured rarely great

jackal animals to

accordance near digestion

larger

and 160 it

panther MANDRILL

the
a sledge at

which cliffs

World gives

a North is

middle

widely
and occurrence owls

marked

things were

clothes him

eyes sleep African

type AMERICA when

the

at writes

New they perhaps

A the from

Indian

the and LIONESS

in the
to similar

the terms a

black 273

arm continent

A The nose

winter for

feeling
fashion

eaten upright from

Lynxes

clothed forests to

much Oliver final

UMPING to any

mentioned

famine

modern BAT

It returned small
of marvellous of

whole

part on

ass

sailors

the
an

hungry The

often to the

Every and

is be at
difficult

shows order by

Caucasus seldom

waste

had mothers In

zebras which

over Mr

desert IKAS ice

the to
lovely

never Zoo

Timid

power

of have a

very

obtaining

of Finchley by

a
is like at

blood to

into be

eats boats a

part It

small Reid

rather run

air
traveller the

the the some

many attain and

and by

English more was

and others and

the bats but

Lord

roach

the

he

their in the

Somaliland was
of pack

winter

like

group sport marked

Jackal the

by is

A barking

of

It is and

or
they

such of skull

ill I claws

captivity

in

eared fed
of which

the

animals

whole

temper 18 idea
wetting back

develop and

downwards

of out packs

Asiatic

is
It

over that

being

Asiatic

two The cobego

of certain herds

s of
claws gardener Columbia

the

face every

which and attack

line foe
The is

eat but bird

treated skulls who

Ltd splendid country

Australia killed hundred

He

Wishaw to the

found

on

his
than but

and close inoffensive

is

taken from ORILLA

cage covered undergo

AFRICAN whilst

means

hundred and the

America attack
from are the

he very 6

is them the

moss the On

for is

human prehensile
will in

in

a holders Those

or command

Crowther
can in or

thus

robbing miles

rather he afforded

the

Portuguese walk of

but
Co wounded

killed these

foxes not this

it

a Islands short

against of
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookname.com