On Tue, Dec 19, 2000 at 03:00:41PM -0500, Derek R. Price wrote:
> 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 Mac,
> etc.
> 

Ack. I'd forgotten about this. Altho I think I may have come up with a
work around. Its not elegant, but if you need to have binarys and also
need to be able to branch/merge code, its the best I can come up with
under the circumstances. 


> 
> > 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 two
> 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 of
> 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.
> 

Excuse me for not snipping this bit. I'm bcc'ing this to a couple people
and I think they'd benefit from knowing this. 


> 
> > 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.

In a perfect world, this would be great. However, we're using cvs to
manage a website, and being able to tag all content/images/whatnot is a
very nice feature. Breaking stuff out would only serve to complicate
things.  Of course, if I cant resolve this I have no choice :)



> 
> It is true that a commit and a diff will not show any differences in the binaries
> 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 to
> 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.

I think I found a solution that will fix things, at least for us. We're
mainly concerned with just using cvs for merging/code management (like its
intended). The binary files are just sort of hanging out on the trunk. If,
after we do a cvs update -kk -dP -j HEAD, we nuke all the binarys and
update them off the trunk, we should be good and avoid commiting broken
binarys. A simple post-merge-pre-commit shell script could do the dirty
work. Something basic like:

for i in `find . -name "*.jpg" ; do
  rm $i
  cvs update -A $i 
done

After that, resolve any conflicts in the code and commit your changes. Its
not elegant, but it does work. I think. We're not using cvs to track the
binary files anyways, and only the trunk gets realeased to production.

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


Eventually splitting the binary/text files into separate modules seems
like the way to go. Then just have a build process to merge them.
Either way, I learned a good bit more about cvs so on the next project
I dont make the same mistakes. Thanks again.


--
Mental

"You are not special. You are not a
beautiful or unique snowflake. You are
the same decaying organic matter as
everything else."
~Tyler~