[Top][All Lists]

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

Re: cvs edit/commit problem

From: Noel L Yap
Subject: Re: cvs edit/commit problem
Date: Thu, 5 Oct 2000 13:14:32 -0400

The purpose of "cvs edit" is to communicate to others that you intend to modify
and commit a file.  Therefore, unless you really do intend to modify and commit
all files, "cvs edit *" is the wrong thing to do.  Don't do that.

Instead, "cvs edit" each individual file as you figure out that you do intend to
modify and commit it.

Of course, there may be circumstances when you would want to do "cvs edit *",
but since they are exceptional cases, "cvs edit *" should not be common

As for the behaviour being a bug, this can be debated.  If you search through
the archives for "namespace" you might find past threads on the topic.  The gist
is that different CVS commands act on different namespaces (eg whether the file
is already in the repository, whether the file exists within the working
directory, ...).

IMHO, the namespace considered by "cvs edit" is incorrect ("cvs edit" should be
allowed on files that don't exist in either the repository or the working
directory), but the namespace for "cvs ci" is correct.  This means that "cvs ci"
should definitely not "cvs unedit" stuff that hasn't really been checked in.


address@hidden on 2000.10.05 12:20:51

Please respond to address@hidden

To:   address@hidden
cc:   (bcc: Noel L Yap)
Subject:  cvs edit/commit problem

I'm experiencing a problem with cvs edit and commit. First of all, we
have a watch on the entire repository and everyone has the CVSREAD
variable set so that checkouts come as read only. This forces all
developers to use "cvs edit" before editing a file. It is common
practice, however, to just do "cvs edit *" so as to edit all files in
the given directory. The problem is on checkin. Just typing

 > cvs commit (or)
 > cvs commit . (or)
 > cvs commit *

works correctly on files that have been modified, but if a file has
not been modified cvs will not run "cvs unedit" on the file. The
result of this is that it leaves the editible file laying around (and
it shows up on cvs editors), very undesirable behavior.  Right now I'm
trying to just get people into the habit of always typing:

 > cvs commit; cvs unedit

This doesn't seem the best solution, though.

Is this a know bug in CVS? Is there a known workaround? Maybe some
insight? One solution I've been toying with is to write a directive in
the loginfo file to go through and unedit the checked in directory,
but the problem with this is that if the user intended to just commit
a single file it will unedit all of them. Furthermore, if no files
were modified then the loginfo doesn't seem to be run at all.

Oh, I'm running CVS 1.10.8 (client/server) on Solaris x86 2.7, if that
makes a difference.


| Richard Jennings Duncan   |
| Graduate Research Assistant    Institute for Signal and Info. Proc. |
| Mississippi State University                       Computer Science |

Info-cvs mailing list

This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

reply via email to

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