[techtalk] File sharing over the internet

Malcolm Tredinnick malcolm at commsecure.com.au
Sun Jul 8 12:55:33 EST 2001


On Sat, Jul 07, 2001 at 09:38:15PM +1000, jenn at simegen.com 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?




More information about the Techtalk mailing list