suggestions for CVS use

Jason Stephenson jason at sigio.com
Fri May 9 10:45:51 EDT 2003


pll at lanminds.com wrote:

> Conflicts can and do happen in ClearCase, if you use private views, 
> since each person gets their own copy of the tree.  But if everyone 
> is working out of the CC equivalent of HEAD, then you need file 
> locking (or at least and agreement that no one can touch those 
> files while they're checked out).

You know, the above reveals a serious flaw in development methodology 
that is used by many corporations and most Open Source projects. 
Ideally, when working on a large project, it should be split up into 
subprojects or modules with clear interfaces between them. Any one 
developer should be assigned a module to work on and that individual 
should not be working on someone else's module. This way, conflicts, in 
the source code control sense, never happen.

All too often, and this has been my personal experience, programmers are 
assigned to work on someting pele-mele and two developers most often do 
have the same file checked out and are both making conflicting changes 
in it at the same time. Often this is because the project wasn't 
properlyfactored to begin with, or that two developers have been 
assigned different fixes that affect the same file by a manager who has 
no idea what the code looks like. Of course the manager isn't going to 
tell either programmer that he's assigned the other to fix something 
else. In his mind, the two fixes are unrelated.

In Open Source projects, conflicts happen under similar circumstances. 
Generally, it's when there hasn't been enough communication on the 
mailing list about who is doing what, or the project maintainer hasn't 
set clear boundaries between tasks.

In KDE, we often ended up with better code by resolving conflicts. It 
usually happened to me when I and someone else were working on different 
bugs or features that affected the same file. When I encountered 
conflicting changes with mine, I'd contact the other developer and 
politely ask what they're working on. I'd then explain what I was doing. 
Often, it turned out that in the discussion one or both of us would come 
up with a more elegant solution that solved both our problems.

So, there's another use for source code control: better code through 
conflicts! :-)




More information about the gnhlug-discuss mailing list