Preferably, the cvs binaries should not be on on
repository path.
initiating cvs in /home/cvsadmin would create the
CVSROOT, the admin files parallel to your path where the cvs is
lying.
and
also the project folders... it would be tricky also to execute the OS perm at
this level, better yo
Hi
All,
I would like to know
if WinCVS exist in french ???
Thanks
Sam
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
>>Always, and only ever, modify a copy of any file if you don't want CVS
>>to see your changes to it!
>
>I can't imagine I'm the only developer that makes local changes to try something out,
>but wants to be sure those changes do not end up in the repository.
Maybe you could setup your system th
On Wed, 2 Apr 2003, Larry Jones wrote:
> Date: Wed, 2 Apr 2003 14:01:30 -0500 (EST)
> From: Larry Jones <[EMAIL PROTECTED]>
> To: Eric Siegerman <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Ignore local changes?
>
> Eric Siegerman writes:
> >
> > CVS should probably print a warnin
[ On Wednesday, April 2, 2003 at 13:51:42 (-0600), Brian G. Peterson wrote: ]
> Subject: RE: Ignore local changes?
>
> > Eric Siegerman writes:
> > >
> > > CVS should probably print a warning in this case, but it doesn't.
> >
> > "This case" is updating a file with a sticky tag or date, which seems
[ On Wednesday, April 2, 2003 at 13:44:00 (-0500), Eric Siegerman wrote: ]
> Subject: Re: Ignore local changes?
>
> No, but you can get part-way there, by explicitly updating to
> the HEAD revision of the file. Find out what the HEAD revision
> is (for the sake of argument, say it's 1.4), and type
On Wed, Apr 02, 2003 at 01:09:44PM -0500, Todd Denniston wrote:
> if on the third hand (hey, where'd that come from?) each engineer needs their
> own config that does not change often and it for some reason can not be tweaked
> to the specific setup by a build script you could each
> branch your ve
> Eric Siegerman writes:
> >
> > CVS should probably print a warning in this case, but it doesn't.
>
> "This case" is updating a file with a sticky tag or date, which seems
> like a good idea to me, too. Anyone disagree?
>
> -Larry Jones
I agree.
A warning like
cvs update myproject
...
myfile.c
On Wed, Apr 02, 2003 at 02:01:30PM -0500, Larry Jones wrote:
> Eric Siegerman writes:
> >
> > CVS should probably print a warning in this case, but it doesn't.
>
> "This case" is updating a file with a sticky tag or date, which seems
> like a good idea to me, too. Anyone disagree?
Sticky *revis
Eric Siegerman writes:
>
> CVS should probably print a warning in this case, but it doesn't.
"This case" is updating a file with a sticky tag or date, which seems
like a good idea to me, too. Anyone disagree?
-Larry Jones
Is it too much to ask for an occasional token gesture of appreciation?!
On Wed, Apr 02, 2003 at 12:28:48AM -0600, Wade Williams wrote:
> But is there a way I can tell CVS - always update this file on an
> update, but ignore my changes on a commit?
No, but you can get part-way there, by explicitly updating to
the HEAD revision of the file. Find out what the HEAD revi
Satyanarayan Nanda writes:
>
> I installed cvs in the /home/cvsadmin directory and initialized the
> directory , using the command
> /home/cvsadmin/cvs -d /home/cvsadmin init
That implies that the cvs binary is inside your repository. While that
isn't necessarily bad, it is unusual and could c
Wade Williams wrote:
I can't imagine I'm the only developer that makes local changes to try
something out, but wants to be sure those changes do not end up in the
repository.
You're not the only developer that has had to deal with a problem like this.
I agree with others who have said that allo
On Wed, Apr 02, 2003 at 07:47:22AM -0700, jda wrote:
> This structure will be preserved when importing?
Yes. To edit your example slightly, you're starting with a
newly-inited repo in /usr/local/cvs-repository, and project
source on a CD:
/mnt/cdrom/Foo/
package1Dir/
foo1.
Wade Williams wrote:
>
> > Yes there is: Do not ever modify the CVS controlled file!
> >
> > Always, and only ever, modify a copy of any file if you don't want CVS
> > to see your changes to it!
> >
> > I.e. this is a build system problem, not a CVS problem.
> >
>
> No, it's not a CVS problem.
>
[ On Wednesday, April 2, 2003 at 11:37:39 (-0600), Wade Williams wrote: ]
> Subject: Re: Ignore local changes?
>
>
> > Yes there is: Do not ever modify the CVS controlled file!
> >
> > Always, and only ever, modify a copy of any file if you don't want CVS
> > to see your changes to it!
> >
> > I.
Hi ,
I have the following directory stucture in the AIX
/home/cvsadmin
/home/satya
I installed cvs in the /home/cvsadmin directory and initialized the directory , using the command
/home/cvsadmin/cvs -d /home/cvsadmin init
Then i created two directories in /home/satya , to add it to reposi
Yes there is: Do not ever modify the CVS controlled file!
Always, and only ever, modify a copy of any file if you don't want CVS
to see your changes to it!
I.e. this is a build system problem, not a CVS problem.
No, it's not a CVS problem.
However, CVS could make life easier with this as an op
[ On Wednesday, April 2, 2003 at 00:28:48 (-0600), Wade Williams wrote: ]
> Subject: Ignore local changes?
>
> I've got a file which I must make changes to on my system. However, I
> don't ever want my changes put back into the repository.
>
> Currently, I handle this by removing the file and re
"Paul Raine (Con)" writes:
>
> Since the Clocks went forward this week my WinCVS has been behaving
> strangely.
> Usually , when I update the files in my sandbox, they go white - indicating
> that I havent edited them. But now they stay red, even if they have
> syncronised with the repository. Als
(CVS will create the intermediate directories if necessary.)
So, to go into more detail, the directory tree looks like:
Foo
package1Dir
foo1.java
foo2.java
package2Dir
foo3.java
foo4.java
package3Dir
..and so on
This structure will be preserved when importing?
(I was hoping, but hadn't really t
Since the Clocks went forward this week my WinCVS has been behaving
strangely.
Usually , when I update the files in my sandbox, they go white - indicating
that I havent edited them. But now they stay red, even if they have
syncronised with the repository. Also the time of the files look to be a
co
22 matches
Mail list logo
