Next: Reverting local changes, Previous: First import, Up: Tracking sources [Contents][Index]
When a new release of the source arrives, you import it into the
repository with the same import
command that you used to set up
the repository in the first place. The only difference is that you
specify a different release tag this time:
$ tar xfz wdiff-0.05.tar.gz $ cd wdiff-0.05 $ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
WARNING: If you use a release tag that already exists in one of the repository archives, files removed by an import may not be detected.
For files that have not been modified locally, the newly created
revision becomes the head revision. If you have made local
changes, import
will warn you that you must merge the changes
into the main trunk, and tell you to use ‘checkout -j’ to do so:
$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
The above command will check out the latest revision of ‘wdiff’, merging the changes made on the vendor branch ‘FSF_DIST’ since yesterday into the working copy. If any conflicts arise during the merge they should be resolved in the normal way (see Conflicts example). Then, the modified files may be committed.
However, it is much better to use the two release tags rather than using a date on the branch as suggested above:
$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
The reason this is better is that
using a date, as suggested above, assumes that you do
not import more than one release of a product per day.
More importantly, using the release tags allows CVS to detect files
that were removed between the two vendor releases and mark them for
removal. Since import
has no way to detect removed files, you
should do a merge like this even if import
doesn’t tell you to.
Next: Reverting local changes, Previous: First import, Up: Tracking sources [Contents][Index]