Tips on Managing Concurrent Development?

An Anonymous Coward queries: "I work on a fairly large-sized project with at least a dozen developers. Advanced tools like CVS and ClearCase allow concurrent development, and provide merging tools to merge in different changes to the same file. This can be a significant productivity gain, particularly with files that are unavoidably common to several developers (C header files, most notoriously). During crunch times, such as before delivery deadlines, we often find that we are checking in changes to the same file several times a day, often hourly. The problem does not seem to be with conflicting changes to the same lines of code, but rather with developers knowing the sequence in which concurrent changes will be checked in. It is not possible to always be aware of who is checking in what and when, so programmers submitting patches to the baseline often have to redo those patches multiple times in a day in order to have them applied. Have other programming projects developed solutions for dealing with this problem?" The submitter proposes another solution, below, how well would it work?

"Take, for example, the extreme case of something like Linux (not only concurrent development, but geographically distributed development), how is this managed? One solution we were contemplating was to try to do an 'air traffic control' type of sequencing and conflict resolution. As early as possible in the development stage, we try to identify what will be finished when, and assign a one-up sequence number to each patch. Developers then know that they will be patching against the baseline that was patched by the patch with the previous sequence number. It is hoped that this prevents a lot of rework of patches. A potential problem with this approach is the need for a responsive central authority to assign sequence numbers. Also, such sequence numbers may have to be rearranged in the face of last minute advances and setbacks in developer progress. Despite careful scheduling and detailed design, it may be impossible to know the exact check-in sequence of patches more than a week or two in advance.

Will such an idea be successful, or is it fatally flawed? Are there better solutions to the problem with less effort? Are we treating symptoms and not the disease (i.e., should we be planning better so that we know patch sequences and dependencies early on)? Management likes to keep staff productively occupied and working up until deadlines, so this usually means a lot of checkins within a short period of time, rather than staged checkins. Can checkins be spread out over time while keeping developers productively occupied?"

Comments

Fly by the seat of your pants.

[ramdac]

Maybe we're just stupid. We dont use any CVS or any other versioning type software to keep track of changes. We dont' check in our code or anything.

Luckily our development is done on the web, we just create folders, and move them up when we're done.

Re:Fly by the seat of your pants.

[b0r0din]

So you know when the next version of Windows is coming out?

Re:SourceForge 3.0 Enterprise Edition

[Anonymous Coward]

Fuck off Taco, log in next time.

Re:Extreme Programming

[slickwillie]

Heck, crunch shouldn't happen if you're managing your development correctly.

If you ever finish a project without crunch time, the marketing guys will find out and have your schedules shortened appropriately.

Cheap Marketing Ploy by VA Software?

[ONU CS Geek]

We've heard in the past few weeks about how VA's Sourceforge on-site is not making the $$$ it needs to be, then we see a "Story" in ./ about developing woes, as well as a few replies from VA guys who are recommending SF.

Conicidence? That's Your call.

HOW DOES THIS ANSWER THE QUESTION?

[Anonymous Coward]

good lord

NICE AD