info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs commandline - best way to see what's modified before commiting?


From: Jim Hyslop
Subject: Re: cvs commandline - best way to see what's modified before commiting?
Date: Tue, 18 Apr 2006 09:39:10 -0400
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Jørgensen wrote:
> Hi,
> 
> Since I'm most used to tortoiseCVS but also would like to learn the
> command line, I didn't yet found out what's the best way of seeing which
> files are new/modified before commiting them, so you can also add
> whatever isn't already added.

I use 'cvs -nq update'. Note that the options precede the command. -n
tells CVS not to actually do anything, but simply to report what it
_would_ do if you let it. -q suppresses the 'Processing directory
foo...' output. The command will generate a list of files that are not
under CVS control, locally modified files, and files which need to be
updated from the repository.

> Is cvs update absolutely safe in that, it doesn't overwriting anything
> newer? Because I think that would do the trick...
> 
> I'm just a bit paranoid if it some day overwrites my new files with cvs
> update, before I commited them...

As Todd says, CVS won't overwrite existing files. It's always best to
make sure your local copy is up to date before committing. First, if
someone else has modified the same file, CVS won't let you commit until
you've updated. Second, if someone else modifies a different file in a
way that's incompatible with your changes, you could break the build.
Breaking the build is a major faux pas. So, whenever I'm about to
commit, my steps are:

1) run 'cvs -nq update'
2) For each file that is unknown (preceded by '?'), do one of:
  a) delete the file
  b) add the file to .cvsignore
  c) 'cvs add' the file
3) If step 1 indicated NO updates or merges were required, commit;
otherwise:
4) run 'cvs update'
5) resolve any conflicts that may have occurred
6) go through the entire build process again
7) go back to step 1

- --
Jim Hyslop
Dreampossible: Better software. Simply.     http://www.dreampossible.ca
                 Consulting * Mentoring * Training in
    C/C++ * OOD * SW Development & Practices * Version Management
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEROvkLdDyDwyJw+MRAmSaAJsHN2ZRptSW0xEXhYl9hDnS0GrMPACfS89h
qCc55zwxuGJfyojA5BlaVNo=
=I0ki
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]