@zelmak said:
In a recently discovered .bash_history:
cvs update && cvs update
It does what I think it does. It may not do what you think it does but that a different matter.
Typically the output of cvs update looks like:
cvs update: Updating some/dir
P some/dir/file-1 (file updated in repository)
P some/dir/file-2 (file updated in repository)
P some/dir/file-3 (file updated in repository)
U some/dir/file-4 (file added in repository)
U some/dir/file-5 (file added in repository)
? some/dir/file-6 (file added locally - not yet added with cvs add)
RCS file: .../file-7,v
retrieving revision 1.2.4.1.2.1.2.3.6.4
retrieving revision 1.2.4.1.2.1.2.3.6.5
Merging differences between 1.2.4.1.2.1.2.3.6.4 and 1.2.4.1.2.1.2.3.6.5 into some/dir/file-7
M some/dir/file-7 (file updated locally)
M some/dir/file-8 (file updated locally)
C some/dir/file-9 (merge conflict)
....
When there are many changes then this output becomes completely unreadable.
That is: getting the relevant important information, merge conflicts and the files that were modified/added locally, is a bit complex.
Three options exist to get the status:
- cvs status which is way too verbose to be useful on a 'large' tree (for small values of large)
- cvs diff which does not show new files that only exist locally
- cvs update
A cvs update after the above update will show:
cvs update: Updating some/dir
? some/dir/file-6 (file added locally - not yet added with cvs add)
M some/dir/file-8 (file updated locally)
C some/dir/file-9 (merge conflict)
When the repository has many changes then I usually run a cvs update after an update because that's the easiest way to get the information I want.
(I actually run 'cvs update -d | grep -v '^cvs update: Updating' since it otherwise display too much useless information)