Gagneet Singh [mailto:[EMAIL PROTECTED] wrote:
> Further to my previous mail, for the cvs command line you can use the
> following command to get the status of the files which have changed.
>
> cvs -n update -P
>
> M File1.dsp
>
> The above tells you that the file name 'File1.dsp' has been locally
> modified. Now you can diff it with the previous version on the server
> by:
>
> cvs diff -wb -i File1.dsp
>
> And find out what has changed.
Not quite - this will tell you what *you* have changed. It will not tell you
what the results of the merge will be, which was the original question.
By the way, on the original question: I usually find it is more trouble than
it's worth to find out what the results would be. I usually just go ahead
with the merge. This approach works best when all developers commit their
changes fairly frequently, and refresh their code frequently as well
("frequently" meaning no more than a day or two between check-ins). Some
people worry about "breaking the build" - i.e. checking in code that won't
compile. Well, if you're doing so much that your code is completely
un-compileable for two days, then you are likely trying to do too much at
once. You need to break down your task into smaller chunks, which can be
checked in as you go.
--
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
