Java Reference
In-Depth Information
With that command all the files from the current working directory on
down will be updated with the most recent versions of the files from the
repository—and not just updated: changes that you have made in your local
files will be preserved and
merged
with the new version of the files.
Here's what a successful merge looks like:
$ cvs update Account.java
cvs server: Updating Account.java
M Account.java
RCS file: /usr/local/srcbank/JavaAppDevLinux/Account.java,v
retrieving revision 1.17
retrieving revision 1.18
Merging differences between 1.17 and 1.18 into Account.java
M Account.java
$
Remember our scenario earlier in the chapter? Our two programmers, Ti
and Kwan, have each modified the same file. If all Kwan changed was adding
a new method, it would merge just fine. But what if they both made changes
in the same region of the source file? Well, the first one to check in his changes
will be fine. His commit will succeed. But the second person to try to commit
changes to the file will find that CVS will report an error:
$ cvs commit Account.java
cvs server: Up-to-date check failed for `Account.java'
cvs [server aborted]: correct above errors first!
cvs commit: saving log message in /tmp/cvsQ9rk01
Now, attempting to update will put
both
versions in your local file, marked
up by certain character strings to highlight and separate the sections. It is up
to the programmer to resolve those conflicts and commit the source once again.
Here's an example of how a conflict might look in a source file:
<<<<< ver. 1.7
for (i=0; i<20; i++) {
myData.callSomething(dollars, time);
}
======
while (i<20) {
myData.callOtherwise(dollars*(i++), time/60);
}
>>>>>
