Re: CVS diff and unknown files.

2005-02-02 Thread Paul Sander
On Feb 1, 2005, at 8:16 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 31, 2005, at 9:30 AM, [EMAIL PROTECTED] wrote: That's not to say that we will *always* know at add time that the commit will fail; failures can occur due to problems in their content which are

Benefit of policies (was Re: Triggers)

2005-02-02 Thread Paul Sander
On Feb 1, 2005, at 12:13 PM, [EMAIL PROTECTED] wrote: [ On Sunday, January 30, 2005 at 16:45:35 (-0800), Paul Sander wrote: ] Subject: Re: Triggers (was Re: CVS diff and unknown files.) It's not so unusual for people who have done SCM for many years on large and varied projects. Well it depends --

Re: Triggers (was Re: CVS diff and unknown files.)

2005-02-02 Thread Paul Sander
On Feb 1, 2005, at 12:03 PM, [EMAIL PROTECTED] wrote: [ On Saturday, January 29, 2005 at 15:22:34 (-0800), Paul Sander wrote: ] Subject: Re: Triggers (was Re: CVS diff and unknown files.) You don't seem to understand the fact that cvs add and cvs rm are supposed to be exactly the same as vi or

Re: 'cvs add' client/server semantics (was Re: Triggers)

2005-02-02 Thread Paul Sander
On Feb 1, 2005, at 12:47 PM, [EMAIL PROTECTED] wrote: [ On Sunday, January 30, 2005 at 22:24:06 (-0800), Mark D. Baushke wrote: ] Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) - there are good reasons for 'cvs add' to have an advisory process (which becomes an

Renaming (was Re: 'cvs add' client/server semantics)

2005-02-02 Thread Paul Sander
On Feb 1, 2005, at 1:25 PM, [EMAIL PROTECTED] wrote: [ On Monday, January 31, 2005 at 08:05:47 (-0800), Mark D. Baushke wrote: ] Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) If I move 'foo.c' to 'bar.c' the CVS/Entries file is going to be confused. In general, doing lots of

Re: CVS diff and unknown files.

2005-02-02 Thread Sergei Organov
Greg A. Woods [EMAIL PROTECTED] writes: [ On , January 31, 2005 at 20:30:21 (+0300), Sergei Organov wrote: ] Subject: Re: CVS diff and unknown files. Don't you wish to even try to understand the suggestion? The suggestion is: invoke *the same triggers* both at 'cvs add' and 'cvs commit'

cvs without a server

2005-02-02 Thread Ed Sutter
Hi, I posted a question the other day and didn't get a response. I'm hoping that the lack of response was not due to the lack of an answer, so I'll rephrase the question... I manage/maintain a small open source project. Internally I was using SourceSafe and I distributed the project to folks as a

Re: Sharing Common Files

2005-02-02 Thread Sergei Organov
[...] The modules file has always been versioned, but one has to remember to tag it with imporant release tags if one wishes to remember its exact state when a given release of any module was tagged; and if one is not very careful then one might have to revert changes in it if one wants to

RE: cvs without a server

2005-02-02 Thread Mark Priest
Ed, I don't think you are going to get too far using cvs for offline access to a repository. If you are running an open source project why don't you just move it to a hosting site like sourceforge.net? Sourceforge provides an Internet-accessible cvs repository for all of your developers free of

Re: cvs without a server

2005-02-02 Thread Ed Sutter
Mark, Thanks for the response. Yea, I have been considering something like that (SourceForge or Savannah); however, it appears to me that while these sites are wonderful for distributed development, the originator of the code loses control (hence, the ability to maintain the direction) of the

RE: user privileges for files / dirs / modules

2005-02-02 Thread Jim.Hyslop
[EMAIL PROTECTED] wrote: I'm hoping this is as simple as this. Though for some reason, my $CVSROOT/CVSROOT files get reset whenever I submit something in there, then I have to manually chmod. I have a taglogs and a logtags file that change to r--r--r--. The logtags file is just a script that

RE: cvs without a server

2005-02-02 Thread Bulgrien, Kevin
I do not think this is the case. The originator need not give anyone else write permission in CVS... at least on SourceForge. One can require contributors to submit patches and then it is up to the originator (or his designees) to accept or reject patches. I think this has the same effect that

Re: cvs without a server

2005-02-02 Thread Ed Sutter
Yea, that is my main concern. I guess I need to reconsider these sites as a more efficient option to solve my problem. Thanks much! Ed I do not think this is the case. The originator need not give anyone else write permission in CVS... at least on SourceForge. One can require contributors to

RE: cvs without a server

2005-02-02 Thread Jim.Hyslop
[EMAIL PROTECTED] wrote: Thanks for the response. Yea, I have been considering something like that (SourceForge or Savannah); however, it appears to me that while these sites are wonderful for distributed development, the originator of the code loses control (hence, the ability to

RE: Overview of files / dirs / modules in the repository

2005-02-02 Thread Jim.Hyslop
[EMAIL PROTECTED] wrote: Is it possible to get some kind of overview of the CVS repository structure without using 3rd party tools like viewcvs? I'm asking because if for example a user forgets the module he checked in two weeks ago. How does he find out the name of the module? In

RE: user privileges for files / dirs / modules

2005-02-02 Thread Christopher.Fouts
-Original Message- From: Jim.Hyslop [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 9:37 AM To: Fouts Christopher (IFNA MP DC); info-cvs@gnu.org Subject: RE: user privileges for files / dirs / modules [EMAIL PROTECTED] wrote: I'm hoping this is as simple as this. Though

Re: user privileges for files / dirs / modules

2005-02-02 Thread Larry Jones
[EMAIL PROTECTED] writes: Yes I started the discussion back then too, and did not get (or I couldn't filter out) a straight answer. So once checked-in with the wrong perms, how does one correct it? By changing the permissions on the RCS file in the repository. The permissions on the working

RE: user privileges for files / dirs / modules

2005-02-02 Thread Christopher.Fouts
-Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 12:15 PM To: Fouts Christopher (IFNA MP DC) Cc: info-cvs@gnu.org Subject: Re: user privileges for files / dirs / modules [EMAIL PROTECTED] writes: Yes I started the discussion back then

Re: user privileges for files / dirs / modules

2005-02-02 Thread Larry Jones
[EMAIL PROTECTED] writes: Thanks, but I believe I've done this, that is, changing the RCS file perms to no avail. Now I remember asking where in the RCS file, and getting not in the RCS file, but of the RCS file. Correct, it's the permissions of the RCS file itself that are used. What

Re: user privileges for files / dirs / modules

2005-02-02 Thread Todd Denniston
[EMAIL PROTECTED] wrote: -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Yes I started the discussion back then too, and did not get (or I couldn't filter out) a straight answer. So once checked-in with the wrong perms, how does one

Re: CVS diff and unknown files.

2005-02-02 Thread Paul Sander
On Feb 2, 2005, at 5:02 AM, [EMAIL PROTECTED] wrote: Greg A. Woods [EMAIL PROTECTED] writes: [ On , January 31, 2005 at 20:30:21 (+0300), Sergei Organov wrote: ] Subject: Re: CVS diff and unknown files. Don't you wish to even try to understand the suggestion? The suggestion is: invoke *the same

Re: CVS diff and unknown files.

2005-02-02 Thread Greg A. Woods
[ On Wednesday, February 2, 2005 at 01:58:31 (-0800), Paul Sander wrote: ] Subject: Re: CVS diff and unknown files. I argue that combining add-time and commit-time triggers is also overloading things too much. You don't seem to understand yet that an add or rm is NO different than any other

Re: Benefit of policies (was Re: Triggers)

2005-02-02 Thread Greg A. Woods
[ On Wednesday, February 2, 2005 at 03:01:32 (-0800), Paul Sander wrote: ] Subject: Benefit of policies (was Re: Triggers) The key to this is not necessarily to have control for its own sake, but to remove places where people screw up. People can only really learn effectively from their

Re: CVS diff and unknown files.

2005-02-02 Thread Greg A. Woods
[ On , February 2, 2005 at 16:02:12 (+0300), Sergei Organov wrote: ] Subject: Re: CVS diff and unknown files. What do we exactly mean by add-time here? The time when cvs add client command is invoked, or the time when new file is to be committed to the repository using cvs commit? I've

Re: error removing a directory from my working directory

2005-02-02 Thread Larry Jones
Kerry Tang writes: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! This is ok if I have one or even two

RE: error removing a directory from my working directory

2005-02-02 Thread Kerry Tang
Title: RE: error removing a directory from my working directory Thanks for your responses. I am still trying to learn and understand how CVS works. From reading the CVS manual, it seems like the only way to remove a subdirectory is to remove all the files within it, and then commit the

RE: Renaming (was Re: 'cvs add' client/server semantics)

2005-02-02 Thread Alexandre Augusto Drummond Barroso
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Sander Sent: Wednesday, February 02, 2005 9:01 AM To: info-cvs@gnu.org Cc: [EMAIL PROTECTED] Subject: Renaming (was Re: 'cvs add' client/server semantics) [snip] I maintain that in the version

Re: 'cvs add' client/server semantics (was Re: Triggers)

2005-02-02 Thread Greg A. Woods
[ On Wednesday, February 2, 2005 at 03:35:48 (-0800), Paul Sander wrote: ] Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) Committing empty files may not be permitted by project policy. Straw man! (and a B.S. policy if I've ever seen one!) No, I don't really want total

Re: CVS diff and unknown files.

2005-02-02 Thread Mark D. Baushke
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg A. Woods [EMAIL PROTECTED] writes: Yes -- we are in almost full agreement, but it cannot use '-n'. (no commitinfo scripts are run with '-n' and I don't think they should be or ever need to be) I believe this statement does not reflect the

how to rollback

2005-02-02 Thread Frank Zhu
If I commit a change that include multiple files, but later need rollback this commit. How can do that provided I have a labeled the repository before commit? Thanks a lot! ___ Info-cvs mailing list Info-cvs@gnu.org