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: Tony Smith <tony AT smee.org>
  • To: "Sergey A. Lipnevich" <sergeyli AT pisem.net>
  • 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 17:37:12 +0100

On Monday 12 August 2002 5:23 pm, Sergey A. Lipnevich wrote:
> I'm not a CVS guru, but here are some answers. BTW,

Thanks Sergey.

> Tony, I remember you sending me to the doc, you should
> read one on CVS :-).

I remember :-) And I bet you enjoyed responding in kind ;-)

Actually I have read some, but with something as important as this I'd rather
swallow my pride and get it right first time. The last thing I want is
someone who *knows* CVS flaming me for trashing his/her changes with my
stupid script.

> 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'

OK, that all looks simple enough.

> > 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.

Got that. Thanks.

> 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.

No problem. Thanks for the info. I'll see what I can come up with.

Tony





Archive powered by MHonArc 2.6.24.

Top of Page