Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hi, one other note: I do see that it is specifically recommended (ala Open Source Development with CVS 3e, pg 164) that -kk *not be used* during merges when binary files are involved. It just seems unfortunate given that -kk would seem to be orthogonal to -kb (i.e., could just be ignored) in this context. Comments? Thanks, -David > Hi Tony, > > > Hi Tony, > > > > > David Hauck wrote: > > > > anyways. I've often wondered if CVS merge could be optimized > > > somehow in this > > > > regard to eliminate/ignore RCS keyword conflicts; they're a > > pain, in my > > > > mind, to deal with currently. > > > > > > > cvs does try to minimise this, and is reasonably successful a > lot of the > > > time. There are some keywords like $Log$, which simply can't be done > > > automatically though. > > > > > > If you're 3-way merging one of the files (the modified file from the > > > user) is going to have the keywords in whatever you do, so it's nearly > > > impossible to handle that. A branch merge to a clean sandbox > can avoid > > > a lot of conflists though. > > > > I only ever do branch merges (i.e., -j <tag> -j <tag> representing one > > branches changes merged onto an active sandbox representing > > another branch). > > Whenever a file being merged has changed in both branches I see the RCS > > keyword conflicts. > > I wanted to report something that I just encountered with my latest branch > merge. I recently moved over to using -kk with the update merge > command and > this (seemed) to work great. At least all the keyword conflicts > disappeared > and I no longer had to manually correct these. *However*, I found out that > handling of binary files is less than optimal in this situation. In > particular the update merge command ends up performing non-binary > operations > on binary files (line endings are converted) as a result and this > messes up > subsequent commits of these files if they're marked as modified in the > merge. > > I would have thought that the -kk option was orthogonal to > repository files > tagged as binary (i.e., doesn't the binary setting take precedence, or, > alternatively, shouldn't the -kk option be meaningless for binary files)? > I'm using 2.0.58d (client/server) - perhaps this has been fixed in later > versions? > > Regards, > -David > > > -David > > > > > Tony > > > _______________________________________________ > > > cvsnt mailing list > > > cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > > > http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs > > > > _______________________________________________ > > cvsnt mailing list > > cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > > http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs > > _______________________________________________ > cvsnt mailing list > cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs