On Wed, Oct 04, 2000 at 04:31:29PM -0700, Annette Waters wrote:
> I am looking for a matrix or tree structure for release numbering schemes.
> i.e,
> three different products that have
> 1) developers version number
> 2) Configuration management build/release number
> 3) Marketing release number
[EMAIL PROTECTED] on 2000.10.04 18:41:20
>Noel L Yap wrote:
>> Yes, this would be a problem. In practice, though, the entire team decides
to
>> use "cvs watch on" on the entire repository (or at least entire modules) so
that
>> they may use "cvs edit" to better support inter-team communicatio
Noel L Yap wrote:
> I haven't formed an opinion, yet, but I will say that allowing only cvsadmin to
> use "cvs watch on/off" may be more difficult than protecting "cvs admin" since
> there are sub-sub-commands to "cvs watch" that normal users should be able to
> use.
Well, right; my point I guess
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
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
On Thu, 5 Oct 2000, Richard J. Duncan wrote:
>
> Is this a know bug in CVS? Is there a known workaround? Maybe some
No it is not a bug. If CVS did this it would be a bad idea for the same
reason that the directive to automatically unedit the file you suggested
would be a bad idea. The known w
[EMAIL PROTECTED] on 2000.10.05 13:25:57
>On Thu, 5 Oct 2000, Richard J. Duncan wrote:
>>
>> Is this a know bug in CVS? Is there a known workaround? Maybe some
>
>No it is not a bug. If CVS did this it would be a bad idea for the same
>reason that the directive to automatically unedit the fi
> 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.
Ok, then take this situation. I see a problem in this file. I w
Howdy --
I'm using cvs 1.10.8 NT Client, Solaris server.
In an area checked out to a branch ( "V50D_SOURCE" )
I try updating a single file to a mainline version:
cvs-1.10.8.exe update -r 1.26 uplog
cvs [server aborted]: missing expected branches in /big2/cvs/master/olf/bin/uplog,v
In a
I tried posting this once, but it didn't seem to go through, so here
I go again...
I am having the problem with the CVS timestamps being off by several
hours. I did a search and read through many of the threads on this
subject, so I know that CVS stores the time in GMT (or UTC - by the
way, i
Noel K writes:
>
> I am having the problem with the CVS timestamps being off by several
> hours. I did a search and read through many of the threads on this
> subject, so I know that CVS stores the time in GMT (or UTC - by the
> way, is UTC the European equivalent term for GMT?)
Not quite; UT
I find it hard to believe that a tool that works across multiple timezones
does not support a way to localize the timestamps? Why not use the TZ
environment variable? This is pretty standard isn't it? It would be nice
to have the timestamps in the repository actually match our local time.
Matt
"Derek R. Price" wrote:
> Well, I view the 'chmod u+w' or 'cvs edit' requirement as a side effect of a
> user watching those files. CVS has to be running in order to send the notices
> user A requested, so user B has to run 'cvs edit' when he wants to edit or else
> there won't be a running proce
[EMAIL PROTECTED] on 2000.10.05 14:28:01
>> 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.
>
>Ok, then tak
Matthew Berney wrote:
> It would be nice
> to have the timestamps in the repository actually match our local time
Oopsie; you don't want to do that if your repository is global, like
most, say, open-source projects. I'd vote for client localization,
though; i.e. cvs logs and historys and so on s
On Thu, 5 Oct 2000, Matthew Berney wrote:
> I find it hard to believe that a tool that works across multiple timezones
> does not support a way to localize the timestamps? Why not use the TZ
> environment variable? This is pretty standard isn't it? It would be nice
> to have the timestamps i
Just a wild guess, but has someone deleted the V50D_SOURCE branch
from the repository?
On Thu, Oct 05, 2000 at 01:29:45PM -0500, Robert Bresner wrote:
>
> Howdy --
>
> I'm using cvs 1.10.8 NT Client, Solaris server.
>
> In an area checked out to a branch ( "V50D_SOURCE" )
> I try updating a si
What difference does it make? If you set your TZ up correctly on the
machine that is using cvs you will see the correct times...
donald
On Thu, Oct 05, 2000 at 12:50:57PM -0700, Matthew Berney wrote:
> I find it hard to believe that a tool that works across multiple timezones
> does not support
> [EMAIL PROTECTED] on 2000.10.05 14:28:01
> >Ok, then take this situation. I see a problem in this file. I want to
> >edit it so I type "cvs edit " Then with further
> investigation I
> >see the problem is really in file2, so I do "cvs edit " and
> >then make my changes in file2. Then I am done
Sorry if this has been asked and answered before -- I don't see it in
the archives.
I am setting up a CVS server which I need to be as secure as
possible. Since two companies must access it, it will be on a public
network. I've used ssh (with CVS_RSH -- no pserver) and given each
user an account
Matthew Berney writes:
>
> I find it hard to believe that a tool that works across multiple timezones
> does not support a way to localize the timestamps? Why not use the TZ
> environment variable? This is pretty standard isn't it? It would be nice
> to have the timestamps in the repository ac
> > >Why does cvs unedit the file that was modified and not
> > unedit the file
> > >that was not modified.
>
> Take this situation: I see problems in file1 and file2, so I "cvs edit file1
> file2".
> I fix file1 and "cvs commit".
> Why should cvs unedit file2? I still want to make changes to fi
Agreed. The server should save whatever time is necessary. UTC seems
reasonable as it is global. For open source repositories, this makes sense.
>From a user's perspective, I don't care if it is done on the server or the
client. When I look at the revision history, (i.e. cvs logs, cvs history,
Matthew Berney writes:
>
> I find it hard to believe that a tool that works across multiple timezones
> does not support a way to localize the timestamps? Why not use the TZ
> environment variable? This is pretty standard isn't it? It would be nice
> to have the timestamps in the repository ac
[EMAIL PROTECTED] wrote:
> This all works well, and seems to be reasonably secure. However, what
> I REALLY want to do is use just one repository for the whole she-bang,
> and have directory-level access control. i.e. a directory accessible
> by both companies may contain a directory accessible b
"Derek R. Price" wrote:
> Yes. You can do it using standard UNIX permissions & groups.
Also take a look, if you're the open source hacking type, at
http://sourceforge.net/projects/cvssupport/. I'm working on a project
there that, among other things, will allow XML files that conform to
http://c
"Richard J. Duncan" wrote:
> It seems arbitrary that it operates on only modified files, do people
> really like this. So far I have seen a lot of "it is right because it
> is the way it is," not "it is right because it seems the proper
> interface."
I might argue the side for the existing imple
[EMAIL PROTECTED] on 2000.10.05 16:42:02
>I would argue that in your situation you should type
>
> cvs commit file1
>
>instead of
>
> cvs commit
What if there were tons of files spread throughout the directory hierarchy?
>It seems arbitrary that it operates on only modified files, do peopl
Thank-you for nailing the reason for putting the cvs edit patches into
the mainstream release of cvs.
I really need to provide sequential editing facilities for
binary/unmergeable files (read locking if you like) and
it is desirable to stay on the main cvs release path (I do not like
maintaining t
Larry Jones wrote:
>
> > The correct $HOME value should then be the users' home? I'm wondering if running
> > a script to set the correct values for $HOME would work... But this solutin seems
> > pretty ugly :-<
>
> $HOME shouldn't be set at all! CVS is perfectly capable of figuring out
> where
Hello!
I had just installed WinCVS 1.1b14. Previously, I was
working on a project on the local site.
But, after a month, I went back to my office to continue
with the proj. Now, I am not able
to connect to the CVS server to checkout my module or ev
On Thu, Oct 05, 2000 at 18:34 -, Noel K wrote:
>
> I am having the problem with the CVS timestamps being off by
> several hours. I did a search and read through many of the
> threads on this subject, so I know that CVS stores the time in
> GMT (or UTC - by the way, is UTC the European equival
Hello all,
Sorry if this is covered in a FAQ, I have not
seen this particular situation covered.
I am using CVS not only for development, but
also as part of a build system. I use a two
repositories for this, one is named "src",
one is named "bin".
I have a few scripts that are in charge of
ch
33 matches
Mail list logo
