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.
"Glen Starrett" <grstarrett at cox.net> wrote in message news:d4oo2k$j41$1 at paris.nodomain.org... > David Hauck wrote: > >>Something I just noticed -- by the file name, looks like you've been > >>merging the branch that the binary doc is on. If you used cvs up -kk > >>-jbranch to do that then you probably messed up the file at that point > >>since -kk tells cvs to treat files like text. I don't see that in your > >>log though, so this might not be applicable. > > > > > > I mentioned this in the continuation of an early thread yesterday. I find > > the -kk "pollution" of binary file treatment during a merge a real drag. It > > seems reasonable to assume that -kk would (should) have no effect on binary > > files (notwithstanding CVS docs that explicitly indicate the incompatibility > > of -kk and binary files during a update merge). You may not have anything to > > add on this, but I wanted to include a comment in this thread as well. > > I've never used -kk with merging, never needed it and AKAICT haven't had > any ill effect by not using it. Is it because you're using $Log$ (it's > known to have merge problems) or some other reason? > > > -- > Glen Starrett Glen & Tony, remember the discusion we had in my "Use Case" thread and I said that you could end up with null change revisions on a parent after merging back and forth from a branch. Well the way I found to avoid the null change revision and a conflict when merging to the branch is to use the -kk option with the merge and no I'm not using the $log$ keyword just the $Id$ keyword. Try this sequence of commands and see what happens. 1. echo $Id$ > a.txt 2. cvs add a.txt 3. cvs ci -m" " a.txt 4. cvs tag -b BR1 a.txt 5. echo new line >> a.txt 6. cvs ci -m" " a.txt 7. cvs up -rBR1 a.txt 8. cvs up -kk -jHEAD a.txt 9. cvs ci -m" " a.txt 10. cvs up -A -rHEAD a.txt 11. cvs up -jBR1 a.txt 12. cvs ci -m" " a.txt 13. cvs log a.txt Now note that a.txt has 5 revisions and revisions 1.3, 1.2.2.1 and 1.4 are all the same with the exception of the keyword $Id$. Had we used the -kk option in step 11 revision 1.4 would not have been created. Further more, note that if I had not used the -kk revision in step 8 there would have been a merge conflict and I can't figure out why. Now if what David is saying is true, and what I'm saying is true then which is the best practice, with or without the -kk ? I'm testing with version 2.5.01 (Travis) Build 1927 on both the client and server, both machines are Windows machines. Thanks Matt S.