Skip to Content.
Sympa Menu

sm-grimoire - Re: [SM-Grimoire]So much time, so little to do. Hold it. Scratch That. Reverse it. OK.

sm-grimoire AT lists.ibiblio.org

Subject: Discussion of Spells and Grimoire items

List archive

Chronological Thread  
  • From: "Sergey A. Lipnevich" <sergeyli AT pisem.net>
  • To: Tony Smith <tony AT smee.org>
  • Cc: eric AT sandall.us, Source Mage Grimoire <sm-grimoire AT lists.ibiblio.org>
  • Subject: Re: [SM-Grimoire]So much time, so little to do. Hold it. Scratch That. Reverse it. OK.
  • Date: Mon, 12 Aug 2002 20:23:28 +0400 (MSD)

I'm not a CVS guru, but here are some answers. BTW,
Tony, I remember you sending me to the doc, you should
read one on CVS :-).

Tony Smith <tony AT smee.org>:

> How can I find out:
>
> a) the list of files in my workspace that have not
been added to CVS.

cvs -nq up | grep '^\?'

This tells CVS to a) not make any changes to repository
or working copy (further WC) with "-n" b) be quiet with
"-q" c) find all lines that start with question mark

Question mark in CVS's status line means that the file
is not a CVS file. This command is recursive, it will
start from current directory inside WC, and proceed all
the way down.

> b) the list of files in my workspace that have changed

cvs -nq up | grep '^M' # modified in your local WC
cvs -nq up | grep '^U' # modified in repository

> c) the list of files in my workspace that have been
deleted.

cvs -nq up | grep '^D'

> d) the correct commands (and flags) to check-in
adds/edits/deletes.

my nomination for the best update command:
cvs -q up -dP

It quitly (no service output, just facts) pushes
changes from repository into your WC. -dP means purge
empty directories and create new directories that are
missing in your WC.

cvs add <file|directory> # self-describing
cvs delete <file> # you'll have to delete the file from
WC before you issue `cvs delete'

Never use `cvs edit' unless you *really* *truly* and
*absolutely* need a lock. Save Nick administrative time
if something goes awry.

>
> and lastly
>
> e) what's the right way to handle the situation where
I'm trying to submit
> changes to a file which someone else has edited since
my last "cvs update"?
>

Intentions: a) commit entire path in WC; b) commit one
file or explicit set of files
Outcomes: 1) there's no conflict (merge) 2) there's a
conflict

a) unless nothing's changed, cvs requires you to update
before you can commit entire path; so update, resolve
conflicts if any, and come back to a)
a1) you just commit; or you can issue `cvs diff -uN' to
look at the current diffs with just updated WC before
you commit
a2) resolve conflicts and start a) again; you can check
with `cvs update' is there are still conflicts; please
see how CVS handles conflicts in the manpage
b) CVS doesn't require updates to these files before
you can commit; as far as I understand it would try to
merge changes in both directions; that means that files
that have changed but are not indended for commit, will
remain locally modified in WC
b1) just commit
b2) resolve conflicts and commit

Good practice is as follows:
Commit one logical change at once with appropriate log
message. Later, there are tools that allow grouping
several file commits with the same author, log message,
and "approximately" the same time, into one logical
commit for observation -- poor man's changesets in CVS ;-).
Don't lock anything, it doesn't pay. We're not talking
things like binary files, Word docs, etc, so there's no
need for locks.

OK, hopefully that's enough. There's always good
resources at http://www.cvshome.org/. I rely on people
to read this and correct me if I'm wrong. Thank you
guys in advance!

--Sergey.

Below is the explanation of CVS status field from
CVS(1). My bloody webmailer is going to wrap the lines,
I'm sorry about that.

U file The file was brought up to date with
respect to the reposi-
tory. This is done for any file that exists
in the reposi-
tory but not in your source, and for files
that you haven't
changed but are not the most recent versions
available in the
repository.

P file Like U, but the CVS server sends a patch
instead of an entire
file. This accomplishes the same thing as U
using less band-
width.

A file The file has been added to your private copy
of the sources,
and will be added to the source repository
when you run `cvs
commit' on the file. This is a reminder to
you that the file
needs to be committed.

R file The file has been removed from your
private copy of the
sources, and will be removed from the source
repository when
you run `cvs commit' on the file. This is a
reminder to you
that the file needs to be committed.

M file The file is modified in your working
directory. `M' can
indicate one of two states for a file
you're working on:
either there were no modifications to the
same file in the
repository, so that your file remains as you
last saw it; or
there were modifications in the repository as
well as in your
copy, but they were merged successfully,
without conflict, in
your working directory.

C file A conflict was detected while trying to merge
your changes to
file with changes from the source repository.
file (the copy
in your working directory) is now the
result of merging the
two versions; an unmodified copy of your file
is also in your
working directory, with the name
`.#file.version', where ver-
sion is the revision that your modified file
started from.
(Note that some systems automatically purge
files that begin
with `.#' if they have not been accessed for
a few days. If
you intend to keep a copy of your original
file, it is a very
good idea to rename it.)

? file file is in your working directory, but does
not correspond to
anything in the source repository, and is
not in the list of
files for cvs to ignore (see the
description of the -I option)




Archive powered by MHonArc 2.6.24.

Top of Page