update -j -kk (was RE: [cvsnt] Re: Corrupted Word Doc)

[Matt Schuckmann]

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