On Sat, Jul 07, 2001 at 09:38:15PM +1000, [EMAIL PROTECTED] wrote: > Conor Daly wrote: > > As a matter of interest, how does CVS cope when: > > 1. I checkout source and start editing. > > 2. You checkout the same source and start editing. > > 3. You finish editing and checkin your version. > > 4. I finish editing and checkin my version. > > > > And we've both modified the same bits of the same files. > > ? > > It notifies the second person of the problem, informs them who > checked in before them, and gives the second person a set of > options. One of the options is a merge, where if the > merge conflicts it includes *BOTH* changes in the merged file, > with some sort of 'here's the problem area' stuff in the file. CVS doesn't give you a choice about what to do. If the two versions edited different areas, it will merge them. Note, however, that your new "merged" version is not committed -- so at this point, _none_ of your changes are in the tree. This is because it's not guaranteed that the merge will make sense. The first person may have just removed a function definition much earlier in the file that you are relying on in your new code, for example. So CVS expects you to check that the file still compiles/reads sensibly (or whatever is appropriate) and then check it in properly. If the changes overlap, it will flag them as a conflict and, as Jenn says, include both versions in the file, surrounded with markers like >>>>>>>>> 1.6 stuff from version 1.6 is here ========= stuff from version 1.5 is here <<<<<<<<< 1.5 So, if you see a file scrolling by with a 'C' as the fist character on the line, it means there's a conflict. Open the file, search for '>>>>' and try to resolve the differences. Cheers, Malcolm -- I've got a mind like a... a... what's that thing called? _______________________________________________ techtalk mailing list [EMAIL PROTECTED] http://www.linux.org.uk/mailman/listinfo/techtalk
