Hello,
* On Mon, Jun 07, 2004 at 05:34:02PM -0400 Larry Jones wrote:
> > However, I now believe its not that simple, as the binary
> > files(only) must be initialized with the -kb option. Is that
> > correct? If so, any suggestions on the simplest/easiest to go about
> > this?
>
> If you can di
Hello,
* On Mon, Jun 07, 2004 at 05:46:20PM -0400 [EMAIL PROTECTED] wrote:
> To create a patch, I could do this:
>
> % cvs co -d buggy -r Release_0_1 MyProj
> % cvs co -d fixed -r Release_0_1_Bugfixes MyProj
>
> % LC_ALL=C TZ=UTC0 diff -Naur buggy fixed > Release_0_1_Patch
>
> ...but I
Spiro Trikaliotis wrote:
> $ cvs rdiff -uN -r Release_0_1 -r Releae_0_1_Bugfixes >
What does the -N flag do? It isn't documented.
--
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)
_
>Hello,
>* On Mon, Jun 07, 2004 at 05:34:02PM -0400 Larry Jones wrote:
>> > However, I now believe its not that simple, as the binary
>> > files(only) must be initialized with the -kb option. Is
that
>> > correct? If so, any suggestions on the simplest/easiest to
go about
>> > this?
>>
>> If y
Hello Bret,
* On Tue, Jun 08, 2004 at 01:50:36PM -0400 Bret A Cooper wrote:
>
> Thanks for your reponse. It prompts a couple more questions. When
> you went back and ran the "cvs admin" command, did you have to run it
> once for every file you wanted to change?
Yes, this has to be run for ever
Hi,
After upgrading cvs due to the vulnerability, I see the following:
cvs commit: warning: Set to use deprecated info format strings. Establish
compatibility with the new info file format strings (add a temporary '1' in
all info files after each '%' which doesn't represent a literal percent)
an
Hello Jim,
* On Tue, Jun 08, 2004 at 09:03:27AM -0400 Jim.Hyslop wrote:
> Spiro Trikaliotis wrote:
> > $ cvs rdiff -uN -r Release_0_1 -r Releae_0_1_Bugfixes >
>
> What does the -N flag do? It isn't documented.
forget it, it is non-existant with rdiff, while it exists with diff. So
it is my faul
I'm trying to get my company to move to CVS from Source Safe. One of the
concerns that people have raised is that CVS does automatic merging of
changes with the repository. Apparently they had bad experiences with PVCS
which did the same thing. I personally never had these problems with PVCS,
bu
At 03:13 PM 6/8/2004, Carucci, Jason wrote:
My understanding is that even when CVS does the automatic merging of
changes, it does not commit them to the repository until you OK the changes
is that correct?
Yes, that is correct. The source is merged in your sandbox by the "cvs
update" operation. Th
Carucci, Jason wrote:
> I'm trying to get my company to move to CVS from Source Safe.
Have a look here: http://www.highprogrammer.com/alan/windev/sourcesafe.html
it may give you additional information to help you convince others.
> BTW, Source Safe also does automatic merging, but I think it
>
On Tue, 2004-06-08 at 15:53, Frederic Brehm wrote:
> The only problem I have had is once when there was a project full of
> "cowboys" who did not bother to communicate with each other and wanted to
> fix everything themselves. The merge problems were a symptom of a
> dysfunctional team and no so
We've followed the proper procedure for removing a subdirectory tree from our
source tree. When we checkout the source tree it no longer creates the
directory hierarchy that we've removed. The checkout process, however, stil
traverses the tree and prints out messages as it does so. Is there a w
[ On Saturday, June 5, 2004 at 17:10:58 (-0700), Paul Sander wrote: ]
> Subject: Re: CVS corrupts binary files ...
>
> Source files are any files that cannot
> be reproduced automatically.
Nope, that's wrong too.
Source files are those files written and edited by humans.
Source _code_ is human (
[ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ]
> Subject: Re: CVS corrupts binary files ...
>
> Yeah, well, sending such hapless people away is easier
> than fixing the tool.
The tool is not "broken" -- I.e. there's nothing to fix!
CVS is designed _only_ for tracking change
[ On Friday, June 4, 2004 at 21:41:02 (-0400), Larry Jones wrote: ]
> Subject: Re: Branch mess, and starting a project with import
>
> Greg A. Woods writes:
> >
> > "cvs import" should really never be used for anything but third-party
> > code that's going to be managed on a CVS-style magic vendor
Greg A. Woods writes [re ignoring the vendor branch]:
>
> It's not really 100% safe though -- at minimum the default branch must
> be returned to the trunk _before_ any other branches are made.
Why? What practical difference does it make whether the branch is
rooted off the trunk revision or the
[ On Saturday, June 5, 2004 at 13:01:48 (-0700), Adrian Constantin wrote: ]
> Subject: Re: CVS corrupts binary files ...
>
> I don't wanna merge binary files, and I'm not likely
> to modify them in my module (project). I just want cvs
> to carry them along with the sources
Then your better tool i
>--- Forwarded mail from [EMAIL PROTECTED]
>> Source files are any files that cannot
>> be reproduced automatically.
>Nope, that's wrong too.
>Source files are those files written and edited by humans.
That's exactly what I said. Read that sentence again.
>Source _code_ is human (and machine)
Spiro Trikaliotis writes [re -N]:
>
> As I said, this option is missing with "cvs rdiff", while it exists with
> "cvs diff" (cvs 1.11.16). Is this difference "by intention", or is it
> accidentially? I would find it very usefull for rdiff.
It's not just useful, it's essential. The option doesn't
Oops, I omitted the Sept. 16 patch. Here it is at the bottom.
--- Forwarded mail from [EMAIL PROTECTED]
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ]
>> Subject: Re: CVS corrupts binary files ...
>>
>> Yeah, well, sending such
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Saturday, June 5, 2004 at 13:01:48 (-0700),
> Adrian Constantin wrote: ]
> > Subject: Re: CVS corrupts binary files ...
> >
> > I don't wanna merge binary files,
>
> Then your better tool is called a "directory" (i.e.
> outside of CVS)
> --
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ]
>> Subject: Re: CVS corrupts binary files ...
>>
>> Yeah, well, sending such hapless people away is easier
>> than fixing the tool.
>The tool is not "broken" -- I.e. there's nothing t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Folks,
Greg writes:
> CVS is designed _only_ for tracking changes in
> human written text files.
Paul writes:
> Keep in mind also that there's a difference
> between "binary files" and "mergeable files".
> The two concepts are in fact orthogonal;
>--- Forwarded mail from [EMAIL PROTECTED]
>Greg writes:
>> CVS is designed _only_ for tracking changes in
>> human written text files.
>Paul writes:
>> Keep in mind also that there's a difference
>> between "binary files" and "mergeable files".
>> The two concepts are in fact orthogonal; there
>
24 matches
Mail list logo
