Kelsang Norpel [EMAIL PROTECTED] writes:
already tried this... but cvs still seems to want to perform a remove on
this file - any idea where it would find a reference to this (now non-
existant) file
Find corresponding line in the CVS/Entries file in your working copy and
remove the line.
--
Stuart Cooper [EMAIL PROTECTED] writes:
[...]
but this is a bit tricky, so making copies, doing cvs update -A and
then moving the copies over and then checking in is perfectly
acceptable.
Did I forget something, or CVS should have been left the original in the
file .#hello.c.1.1?
--
Sergei.
[EMAIL PROTECTED] (Larry Jones) writes:
Stuart Cooper writes:
but this is a bit tricky, so making copies, doing cvs update -A and
then moving the
copies over and then checking in is perfectly acceptable.
As long as you're the only one making changes. If there's a possibility
of
[EMAIL PROTECTED] (Larry Jones) writes:
Sergei Organov writes:
How is it different from update -A *without* copying anything on top of
it? My experience is that update -A would perform regular merge of
current changes into the head version. Am I missing something?
You're missing
Greg A. Woods [EMAIL PROTECTED] writes:
[ On Wednesday, February 2, 2005 at 15:33:28 (-0800), Mark D. Baushke wrote: ]
Subject: Re: CVS diff and unknown files.
Greg A. Woods [EMAIL PROTECTED] writes:
Yes -- we are in almost full agreement, but it cannot use '-n'. (no
commitinfo
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
[...]
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
Paul Sander [EMAIL PROTECTED] writes:
On Jan 30, 2005, at 2:18 AM, [EMAIL PROTECTED] wrote:
Todd Denniston [EMAIL PROTECTED] writes:
Sergei Organov wrote:
Todd Denniston [EMAIL PROTECTED] writes:
If cvs -n commit runs the triggers to do your check(see my
question above), I have
Paul Sander [EMAIL PROTECTED] writes:
On Feb 1, 2005, at 2:51 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
Would you post a message stating your point of view, completely,
please? Thanks!
I need a way to generate 'cvs diff' against read-only repository. To
Paul Sander [EMAIL PROTECTED] writes:
On Jan 31, 2005, at 9:30 AM, [EMAIL PROTECTED] wrote:
[...]
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' time,
-- there is no need for separate triggers.
I
Paul Sander [EMAIL PROTECTED] writes:
On Jan 30, 2005, at 6:40 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 28, 2005, at 8:50 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
[...]
Todd Denniston [EMAIL PROTECTED] writes:
Sergei Organov wrote:
Todd Denniston [EMAIL PROTECTED] writes:
If cvs -n commit runs the triggers to do your check(see my
question above), I have another question: in a remote server setup
(i.e., :pserver:, :ext:) which test was failed
Paul Sander [EMAIL PROTECTED] writes:
On Jan 28, 2005, at 11:36 AM, [EMAIL PROTECTED] wrote:
[...]
If you consider my suggestion, there will be no such a beast as
add-to-working-copy-time trigger. The commit trigger will notice the
file is new and invoke appropriate additional actions (if
Paul Sander [EMAIL PROTECTED] writes:
On Jan 28, 2005, at 9:34 AM, [EMAIL PROTECTED] wrote:
Sergei Organov wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
If cvs add will only warn about the problems, -- that's
OK with me as a user
Paul Sander [EMAIL PROTECTED] writes:
On Jan 28, 2005, at 8:50 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
[...]
Just to understand your point better, do you propose 'cvs add -c
new_file' and 'cvs ci
[...] Sorry, I've skipped all the above.
Paul, your vision of the software world, including client/server,
wrappers, triggers, scripts, libraries, security, etc. seems to be so
unusual that it makes it very difficult to discuss these things with
you. It seems you leave in an entirely different
Paul Sander [EMAIL PROTECTED] writes:
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
[...]
Just to understand your point better, do you propose 'cvs add -c
new_file' and 'cvs ci new_file' run exactly the same set of triggers?
Different sets?
I think the consensus in the last
Todd Denniston [EMAIL PROTECTED] writes:
Sergei Organov wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
[...]
Just to understand your point better, do you propose 'cvs add -c
new_file' and 'cvs ci new_file' run exactly the same
Paul Sander [EMAIL PROTECTED] writes:
[...]
What register adds in the repo nonsense are you talking about? The
proposal I made simply requires a contact with the server to run the
add-time triggers; it does NOT require add-time modifications of the
repository by the CVS server itself. If the
Todd Denniston [EMAIL PROTECTED] writes:
Sergei Organov wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote:
[...]
Is there any sound reason why 'cvs add' and 'cvs remove' commands
require *write* access to the repo?
I believe what
Todd Denniston [EMAIL PROTECTED] writes:
Sergei Organov wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote:
SNIP
It's unclear if that particular change will be made, or if made
whether or not it will stay. The requirement to supply add
Greg A. Woods [EMAIL PROTECTED] writes:
[ On , January 21, 2005 at 20:06:37 (+0300), [EMAIL PROTECTED] wrote: ]
Subject: CVS diff and unknown files.
Is there a way to include contents of unknown files into the 'cvs
diff' output?
I did try the -N switch but it doesn't seem to do the
Todd Denniston [EMAIL PROTECTED] writes:
[...]
$ echo dummy dummy.txt
$ cvs add -m dummy.txt
cvs [server aborted]: add requires write access to the repository
Until the Fix that Greg described late last year is put in, you can (I
think) trick cvs at least for files.
***begin
Paul Sander [EMAIL PROTECTED] writes:
On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote:
Todd Denniston [EMAIL PROTECTED] writes:
[...]
$ echo dummy dummy.txt
$ cvs add -m dummy.txt
cvs [server aborted]: add requires write access to the repository
Until the Fix that Greg
Spiro Trikaliotis [EMAIL PROTECTED] writes:
Hello,
I have a question regarding two projects, which do the same for Windows
and/or Linux, and share many files of the common code base.
Unfortunately, the build systems or not compatible: GNU Make with gcc on
the one hand, Microsoft's
work [EMAIL PROTECTED] writes:
Ok, Based on 2 emails from this list, the CVS manual, and the Essential CVS
book, I'm confused about the whole merge what tag where stuff. I hope I craft
this email to get a clear answer to unfog my head. Project Name: testproj
Local Sandbox is: rel_1/testproj
Jim.Hyslop [EMAIL PROTECTED] writes:
work wrote:
[...]
At this point, I'm not overly concerned about deleted or added files
(to me they are much easier to deal with since the entire file is
involved).
You will have to use 'cvs add' and 'cvs remove' to have these files added or
removed
Andy Jones [EMAIL PROTECTED] writes:
As promised, a diff to the manual.
This is a context (-c) diff on the 1.11.14 version of the file. Please let
me know if that's not okay.
[...]
+ This will work for locally modified files, but not
+ for locally deleted ones.
Did you check it
Andy Jones [EMAIL PROTECTED] writes:
Did you check it doesn't work for locally removed files (for which cvs
remove has been executed)? If it does, the description needs further
cleanup, I think.
What about locally removed directories?
In both cases cvs tag warns or errors, then bombs out,
Andy Jones [EMAIL PROTECTED] writes:
Jason Carucci
[...]
Derek Price
The work-around, and a pretty straight-forward one I should think, is to
commit your changes before tagging.
No, no. I don't want to remove the files. I just want to not tag them. Now
it looks like I will have to tag the
Andy Jones [EMAIL PROTECTED] writes:
Why can't you just choose the files you want to tag and run the TAG command
only on those. This way only those files get tagged and not the complete
module, which is not want you as it is want to happen.
Because I have 12,766 files, and I want to tag all
Hi,
CVS (1.11.1p1) doesn't seem to allow add/remove to be made against a read-only
repository. This behavior makes it inconvenient to work with such repositories
(I mean public CVS repositories of open-source projects). In particular,
locally rm'ed files re-appear as soon as update is invoked,
Jim.Hyslop [EMAIL PROTECTED] writes:
Sergei Organov wrote:
CVS (1.11.1p1) doesn't seem to allow add/remove to be made against a
read-only repository. This behavior makes it inconvenient to work with
such repositories (I mean public CVS repositories of open-source
projects). In particular
Iakov Glubokiy [EMAIL PROTECTED] writes:
Hello all,
I'd like to discuss some thoughts about merging from a branch several
times. AFAIU, Cederqvist ommited the tiny fact that using double -j
one can lose some data. He says:
[...]
Now suppose that development continues on the R1fix branch:
34 matches
Mail list logo
