[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: -kk and -kb aren't getting along

From: Derek R. Price
Subject: Re: -kk and -kb aren't getting along
Date: Tue, 19 Dec 2000 15:00:41 -0500

Mental wrote:

> Now, the thing is, I've done some experimenting and the version number
> isnt changing. Commits dont ask for a log message, so I imagine that nothing
> is happening to the binarys. It seems to me that when you do the update -kk
> -j to do the merge that nothing 'bad' is being done to the binary files.

It's possible that nothing bad is being done to the binary files.  This is only
the case if there are no keyword strings in the binary files and nothing that
looks like a line feed to get converted to '\r\n' under Windoze or '\r' under 

> Functionally, how is -kk different from -kb? If I checkin a binary with
> the sticky options -kk, what 'bad' thing could happen to it? You're
> correct in that the -kb tag on the trunk is not overridden by the -kk tag
> on the branch. There doesnt _seem_ to be anything broken. Doesnt the -kb
> tag tell cvs (among other things) not to look for keywords to expand?

-kk will find a keyword string and sub it into only the keyword.  Thus
'$Date: <sometime>$' becomes '$Date$'.  This is nice for merging text because 
revisions of a file, which almost always will have different date strings, will
merge smoothly.

Unfortunately, if, say, somebody wrote some C code like the following:

    foo_c_date = "$Date: <somedate>$"

as used to be a common practice, then -kk causes shortening of the data segment 
a binary so that "$Date: <somedate>$" becoming "$Date$" throws off all sorts of
indexes into code & data.  It becomes a real mess.  I believe line ending
substitution happens in -kk mode as well.

> I think I'm fairly safe at this point. Nothing seems to have broken in my
> tests. It seems (and this is pretty untested) that as long as the initial
> add was done with the -kb switch that things are ok. I would be very
> pleased if this this were the correct conclusion.

Some sort of update after your merge to remove the '-kk' tags is necessary to
ensure that the binaries in your local area are still usable.  Like I said, I am
not sure which ones will work in all cases.  The safest procedure is probably to
remove all binaries after the merge, eliminate sticky keyword modes on your
remaining files, then update with fresh copies of the binaries.

It is true that a commit and a diff will not show any differences in the 
because they both honor the keyword expansion mode.

Oh, yeah.  If I remember correctly, this gets really tricky if you actually
altered one of the binaries on the source or destination branch and CVS attempts
to merge binaries.  Hmm.  Maybe that can't happen anyway if '-M COPY' is set.
Anyhow, there are issues here I am probably unaware of.

Okay, I'll correct my earlier statement.  The safest way to do this is probably 
keep binaries out of the merging process altogether.  This could be accomplished
most of the time with a more loosely bound directory structure, i.e. one with
binaries and mergables in directories that can be specified separately.

If you discover a merging procedure that works consistently, please, document it
and send it to the list.

Again, no warranties.  I might be wrong.  Make copies of everything before 
your valuable code.  If you break anything, it's your own darn fault.


Derek Price                      CVS Solutions Architect ( )
mailto:address@hidden     OpenAvenue ( )
All those who believe in psychokinesis raise my hand.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]