Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Tips on Managing Concurrent Development?

Cliff posted more than 12 years ago | from the dealing-w/-many-hands-in-the-cookie-jar dept.

Programming 256

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?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Fly by the seat of your pants. (3, Funny)

ramdac (302865) | more than 12 years ago | (#3170620)

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. (0, Insightful)

Anonymous Coward | more than 12 years ago | (#3170911)

Stop! You're frightening me.

Privation of source code control is one of the hallmarks of a
sw development disaster waiting to happen. Expect to experience excruciating pain when this practice finally catches
up to you. 8^(

Tips on widening pages! (0, Insightful)

Klerck (213193) | more than 12 years ago | (#3170624)

It looks like this may be one of the few IE-bug page widenings! It is truly a sad day!

.I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter .telling .you .that .you .don't .have .enough .charaters .per .line .that .really .sucks .when .that .happens .and .you .have .to .put .some .lame .lameness .filter .defeater .text .in .there .i .wonder .how .many .people .will .read .this .whole .comment .I .certainly .hope .it .doesnt .annoy .too .many .people .This .is .just .the .beginning .because .PAGE .WIDENING .IS .BACK .I .like .wide .pages .I .wish .all .pages .could .be .as .wide .as .this .dont .you .wide .pages .are .much .cooler .than .those .narrow .pages .you .are .used .to .reading .because .you .dont .have .to .worry .about .the .lameness .filter

Re:Tips on widening pages! (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3170634)

your monkey-dick brain is the saddest thing in the world

SourceForge 3.0 Enterprise Edition (4, Informative)

Anonymous Coward | more than 12 years ago | (#3170626)

(disclaimer: I am a VA Software employee)

I know this sounds corny, being said on a VA property such as Slashdot, but SourceForge 3.0 [vasoftware.com] is easily the best concurrent development environment i have ever used. It was my love for Sourceforge which made me pursue a job at VA Software in the first place! The fully web-based administration hides all the niggling details of commandline cvs tools and makes managing huge projects a piece of cake.

In short, if you haven't been to VA Software's site [vasoftware.com], you don't know what you're missing.

Re:SourceForge 3.0 Enterprise Edition (0, Funny)

Anonymous Coward | more than 12 years ago | (#3170729)

Fuck off Taco, log in next time.

Re:SourceForge 3.0 Enterprise Edition (0)

Anonymous Coward | more than 12 years ago | (#3170907)

Thanks for the tip... but I paid for NO FUCKING ADS!

The crap the slashdot crew are pulling with this ought to be ILLEGAL.

Re:SourceForge 3.0 Enterprise Edition (0)

Anonymous Coward | more than 12 years ago | (#3170935)

You've obviously never worked on a large or even a medium size project.


Anonymous Coward | more than 12 years ago | (#3170990)

good lord


I recommend SourceForge OnSite (c) (3, Interesting)

Anomolous Cow Herd (457746) | more than 12 years ago | (#3170630)

Even though it is backed by CVS (and you could possibly get away with using just that), SourceForge OnSite (c) (sold by VA Software at a reasonable price) makes managing CVS and concurrent code development a snap! Just plug it in and code away with the knowledge that you are paying for the support services of one of the leading vendors of enterprise-grade Linux solutions.

I wouldn't, however, recommend working with anything from Microsoft. Benchmarks and real-life statistics have shown that their source control solutions are not only slower, but are also less stable and more likely to corrupt your source tree. I hope you have backups!

Re:I recommend SourceForge OnSite (c) (1, Informative)

Anonymous Coward | more than 12 years ago | (#3170671)

The above may be a shameless plug, (+ some anti-MS FUD) but I do agree SourceForge is the best I've seen so far.

12 people a large project ??? (5, Insightful)

bstrahm (241685) | more than 12 years ago | (#3170633)

I don't think so, but then to many people this might be large...

Of course some of these problems sound like lack of planning early in the game...

For example changing headers that two developers need... The only headers that two groups need should be interface headers, these should be set early and not need a lot of change, with any change taking both developers changing the code internally...

Another note, I get really worried when people say that process problems only show up at the end crunch time. If it is crunchtime it is time to use all of your processes, because the processes should be designed to produce the best bug free code the quickest... otherwise it shouldn't be in the process...

That is just my 2c worth however

Re:12 people a large project ??? (0, Insightful)

Anonymous Coward | more than 12 years ago | (#3170818)

These are all things that software development houses learn as team and project sizes grow. I would venture to guess that this is the largest project this company has done yet, but probably in a few years they'll be working on bigger projects and most of the things you mention will be in place. At least, that is how it has been where I work; the larger the projects get, the more structured you learn to work, and planning becomes more and more important.

Lack of planning is often a management problem. I know where I work, several times we've had problems where management promises what amounts to essentially working versions of the program midway (or earlier) through the project development. This is equivalent to letting someone start moving into their new house halfway through building it, which is just nuts. Unfortunately, in software, you then end up putting in the most horrible hacks just to get things to work for the ridiculous milestone deadline, planning and modularity and good design go to pot, and the program becomes a painful mess to maintain and extend. Although its improved a lot, partially due to lots of complaining from me, and management slowly sort of starting to realise the problems it creates.

Re:12 people a large project ??? (1, Interesting)

Anonymous Coward | more than 12 years ago | (#3170910)

Another note, I get really worried when people say that process problems only show up at the end crunch time. If it is crunchtime it is time to use all of your processes, because the processes should be designed to produce the best bug free code the quickest... otherwise it shouldn't be in the process...

Of course all real programmers should realise that this attitude is either from someone in academia, someone who never worked on a big project with real deadlines, or he's lying.

CVS (1)

StarFire_FIN (532729) | more than 12 years ago | (#3170637)

I always thought CVS could be used to do something like this. I mean, keeping programmers productively occupied.

I haven't really studied it all that much, so I could be wrong(probably am).

fifth post! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3170639)


Better Solution: Use CVS or ClearCase Properly! (5, Informative)

noahbagels (177540) | more than 12 years ago | (#3170647)

I currently work in an organization with 75 Engineers (50 USA, 20 India, 5 Asia) - and we use CVS. It's free, easy to use, and has a simple feature set so that more than one person has enough knowledge to do things like branching and merging branches.

We nearly never have merge problems. It is standard procedure that people keep their tree up-to-date with the cvs tree, and thus conflicts rarely arrise. Even at crunch-time, I probably have one merge conflict every 2 weeks, and with CVS - you are notified of the conflict and it is wrapped with CVS comments.

To put this in perspective - while at Oracle with 1000s of engineers working on the same tree, we used ClearCase and it was awesome. The difference here is that there was much steeper a learning curve, and no normal engineers could actually do complex tasks - i.e. create branches etc. We had a complete groud dedicated to ClearCase.

Educate your engineers - and politely have the senior engineers tell them when they mess up - enforce a policy that people must update the source every day that they plan on checking-in files.

Also - I don't know what CVS versio you are using, but the latest free WinCVS client will not allow you to check in a file with a conflict! It will force you to update/merge/resolve the conflict before updating the tree. I highly recommend CVS and WinCVS due to the ease of use and cost.

Re:Better Solution: Use CVS or ClearCase Properly! (1, Redundant)

Lumpish Scholar (17107) | more than 12 years ago | (#3170790)

It is standard procedure that people keep their tree up-to-date with the cvs tree ...
What he said. Run cvs update early and often, to merge others' changes with yours, and to detect conflicts ASAP. Also, fully automate your builds, require a clean build before check in, and make it anathema [dictionary.com] to "break the build."

Re:Better Solution: Use CVS or ClearCase Properly! (3, Interesting)

Rogerborg (306625) | more than 12 years ago | (#3170803)

  • To put this in perspective - while at Oracle with 1000s of engineers working on the same tree, we used ClearCase and it was awesome. The difference here is that there was much steeper a learning curve, and no normal engineers could actually do complex tasks - i.e. create branches etc. We had a complete groud dedicated to ClearCase.

To put this in perspective, I currently handle the Clearcase side of a transatlantic development effort, with maybe 200 developers. The other side uses Continuus (office politics, don't ask). They have a complete config/build group. They even have a tools group that does nothing but evaluate, purchase and support tools for the config/build group. Until very recently, I handled the Clearcase side on my own. Part time (I'm a developer). It got to the stage where I would actually take the source from Continuus, import it to Clearcase, produce reports, perform a build and test it before the Continuus team could do it, and my builds got used in preference to theirs.

Just goes to show, there's always a worse system, or other alternatives to explore. The developers who're used to using Continuus are all in love with Clearcase, and rebellion is brewing. One guy said that he'd learned to do in Clearcase in two weeks what it had taken him two years to learn in Continuus. And yet I agree with you: CVS is even easier than Clearcase, and does everything you'd need to do on a typical project!

Re:Better Solution: Use CVS or ClearCase Properly! (5, Informative)

PD (9577) | more than 12 years ago | (#3170816)

We nearly never have merge problems. It is standard procedure that people keep their tree up-to-date with the cvs tree, and thus conflicts rarely arrise

I'll second this: At many companies I have heard over and over that CVS sucks because of the conflicts. When I inquire further, I find out that people never or rarely use the cvs update command to synchronize. cvs update should be executed almost like a nervous habit, or at least a couple times a day. More if code is being checked in frequently, or if you are working on the same code as someone else. Use the watch commands in cvs to be notified when others edit your files.

It's a shame, really, because programmers seem to be afraid of cvs, preferring a more primitive tool such as rcs or pvcs. cvs lets programmers work in the style that is most natural in an open-source arrangement, and in my opinion can be a far more productive environment than a systems that locks the rest of the team out of critical files.

Re:Better Solution: Use CVS or ClearCase Properly! (0)

Anonymous Coward | more than 12 years ago | (#3170852)

The difference here is that there was much steeper a learning curve, and no normal engineers could actually do complex tasks - i.e. create branches etc. We had a complete groud dedicated to ClearCase.

Did you use branches in ClearCase, but not now in CVS? Branches are a main feature of ClearCase, but I've heard they're harder in CVS. I've found ClearCase to be quite simple, except for branching, which I think leads to inherent complexity (i.e. not ClearCase's fault). Otherwise I can't think why ClearCase would be so much more complex than CVS.

Re:Better Solution: Use CVS or ClearCase Properly! (1)

sn0wcrsh (157693) | more than 12 years ago | (#3170872)

Merging in CVS is a PAIN IN THE ASS
(compared to the nifty merge tools in ClearCase).

Clearcase = Flexibility (but complex)
CVS = Rigid (but easy)

Can anyone recommend a decent merge tool for cvs?
I work for a company that has HUGE repositories and
the current tools really SUCK.

Re:Better Solution: Use CVS or ClearCase Properly! (0)

Anonymous Coward | more than 12 years ago | (#3170979)

Yea, if your stupid and slow you will have conflicts and need to merge. But use ExamDiff and it's a breeze ( and also free)!

But there's no excuse for being stupid and slow.

cvs is cool by me.

Re:Better Solution: Use CVS or ClearCase Properly! (0, Flamebait)

_Marvin_ (114749) | more than 12 years ago | (#3170856)

That's exactly what I thought first. Then I
realised: cvs *won't let* you check something
in if you haven't run cvs update on a file where
it would be necessary.
Yes, it is possible to create the situation the
original poster describes, but only by
circumventing the usual cvs mechanisms - cvs
makes this possible, but I can't believe someone
(or even a group of people) does this without
realising they're doing something terribly
In fact, I believe the original post is just a
highly successful troll!

Re:Better Solution: Use CVS or ClearCase Properly! (1)

mrm677 (456727) | more than 12 years ago | (#3170925)

The difference here is that there was much steeper a learning curve, and no normal engineers could actually do complex tasks - i.e. create branches etc. We had a complete groud dedicated to ClearCase.

You are kidding me, right? I haven't used Clearcase for about a year but yet I still remember "cleartool mkbranch ". If Oracle software developers can't manage making branches on their very own CM tool, then my confidence in Oracle's DBMS just plummeted!

Subversion! (3, Interesting)

Pointer80 (38430) | more than 12 years ago | (#3170650)

Check out subversion [tigris.org].
It's CVS, but better and based on WebDAV for RPC and BerkeleyDB for storage.



Modular Isolation (5, Insightful)

pyrrho (167252) | more than 12 years ago | (#3170651)

The only thing I know that really works (i.e. "is simple") is to lessen the conflicts through design... that is, two people shouldn't HAVE to edit the same modules. Or at least not the same lines of the same modules (those are the only merges that are really painful). Similarly, if you have well understood specification for modules then there should not be a problem when the lines edited don't overlap, because the functions and modules will continue to behave to the spec, which is all the other code can expect.

I know this isn't really easy to do (can't be done retroactively), and doesn't really fit all cases (such as near a release when there is a lot of chaos), but it's the only elegant solution I know of, all the rest are more brute force.

Re:Modular Isolation (2)

Old Wolf (56093) | more than 12 years ago | (#3170681)

Yes, I agree with this one: the best solution is to design your project so that you don't need to have two people working on the same piece of code at once (and if my some chance you do, then one should wait for the other to finish before starting).

Re:Modular Isolation (1)

/dev/trash (182850) | more than 12 years ago | (#3170806)

Yes, I agree with this one: the best solution is to design your project so that you don't need to have two people working on the same piece of code at once (and if my some chance you do, then one should wait for the other to finish before starting).

You have GOT to be kidding??? My last job was one that had me and 4 others on the 'bug fixes' team. Any issue taht camefrom the field was handled by us. The other team was the new development team. Now you'd think that new dev and existing dev were two different environments but not with us. We had to go to the object guy and have him manually check us out a kbase. He then 'locked' it so he wouldn't check it out to anyone else. If you wanted code that was locked. Too bad. Sure we could fix it locally and we did many a time but to get into the mainstream was impossible unless you gave those changes to the locker and hoped he used them or you waited til it was unlocked.

Being we were the 'on call' team having something locked was near death as your numbers went up and up and no one cared that you had nothing to do with it.

Re:Modular Isolation (2)

edhall (10025) | more than 12 years ago | (#3170871)

In those cases where you do have to have two people work on the same code at the same time, seat them elbow-by-elbow. If a bunch of people need to work on the same code, move their workstations into a conference room.

When the crunch is over, go back to your normal work areas and vow to plan better on the next project.


Re:Modular Isolation (2)

renehollan (138013) | more than 12 years ago | (#3170730)

I second this. However it flies in the face of "load balancing".

You know, 12 UI changes to be made divided by 6 developers = 2 UI changes per developer. Nice "perfect" load balancing. Never mind that 5 of those 6 now have to learn the structure of the UI system developed by the 6th and not yet documented for public consumption and that the 6th could have implemented all 12 changes himself in the same time as the entire team.

Oh yes... such "load balancing" does expose merge "hot spots" pretty quick.

I've seen two conflicting approaches: check in to a common branch and trust the source code control system to keep things sane (Clearcase can do this, CVS sticky tags can as well). The trouble here is that people wait for exclusive checkouts, or run the risks associated with non-exclusive checkouts. The other approach is to maintain a branch for every developer and merge. This resolves the exclusive checkout problem, but requires discipline and avoidance of hot spots and architecturally-based task assignment.

I worked in a shop that started with the branch per developer approach (not a problem with Clearcase, but from what little I know about CVS, this may not be practical), and quickly abandoned it because too many people played with the same code causing merge nightmares (exacerbated by management's load balancing based on estimate lines of code added/changed without regard to architecture or skill).

I now work in a shop that sticks to CVS, and people generally know who's playing where. Sticky tag confligs occur rarely.

Personally, I like the idea of modular isolation, because it lets you use the one branch per developer approach (well, with Clearcase, at least) if you want, letting people test changes to code their not supposed to be "officially" changing (it sometimes that you find a bug in code you shouldn't "officially" change).

Re:Modular Isolation (1)

jackb_guppy (204733) | more than 12 years ago | (#3170915)

This is the ONLY way.

If you have developers all over the same peice of code... YOU ARE NOT MANAGING! I delevoped multiple million line systems with 1000's of modules. Good naming conventions. Good front end design. Then there is no need for CVS.

We did not allow programmer is to even make their own copy of the code, nor make a backup copy.

Why? you ask.

Trash. Thats right, trash! When does a programmer know it is safe to delete the copy? Never and when you more than one doing this 1000 programs became 5000 or 10000. Which one is right.

We used automated process to insure object and source matched - it ran every night. Once a week, a check program was ran to identify rogue code - those nasty personal copies. We backed them and deleted them.

If bug creaped into the code, I did not how or went, the rules were simple - you found it, you killed it.

My expection was each programmer as Q/A for all who was in there prior. When you are done with a program, you are argeeing in meets or exceeds all design requirments. Yes exceeds. I wanted the system as a whole to improve. When you are in program and find that do-loop is being ran 2000 time every time, and you correct it to run once, and the program still meets the needs... then you exceeded. But at the same time, my programmers ALWAYS betted their ass.

We worked hard and played hard -- we had FUN.

merge? (1)

bob_clippy (562460) | more than 12 years ago | (#3170669)

Most version control systems have an automatic merge utility which makes it easy to handle simple concurrent changes, such people independently adding #defines and typedefs in headers. For .c and .cpp files, you should break them up to minimize developer thrashing (I apologize if you've heard that 100 times already).

Use Continuous Integration (3, Informative)

rimsky (106475) | more than 12 years ago | (#3170674)

One solution to avoid patching problem is to use continuous integration [martinfowler.com]. It's an integration technique that builds your source multiple times a day, getting all the latest source code from the CVS tree, and building from that code. If anything fails, the offending developer gets warned. Mozilla uses the same thing, calling it TinderBox [mozilla.org]. It's one of the principles of Extreme Programming, and seems to work quite well at our company.

Re:Use Continuous Integration (2)

richieb (3277) | more than 12 years ago | (#3170827)

Agreed 100%!

We develop in Java and use CruiseControl [sourceforge.net] continous build tool. It checks every five minutes if anyone checked anything in, and if so it runs the build. At a previous job I used Tindebox and it was equally helpful.

Trying to schedule changes (2)

kingdon (220100) | more than 12 years ago | (#3170689)

Well, I've been on projects in which people say "oh, you rearrange that code first, then I'll do my thing" (more informally than your "air traffic controller" example, but kind of the same thing). It can sometimes be helpful, but all too often it gives an excuse for inaction ("well, I couldn't do xxx because yyy had to happen first"). One thing which can help a bit is continuous integration - run "cvs update" often and checkin as often as you can (say, whenever your automated tests pass). Oh, and of course trying to not do everything right before the deadline (although it can be hard to change a culture and I'm not sure it is worth it). Other than that, I don't know of any magic bullets - just to say that dealing with the pain of continuous (or at least frequent) integration is better than the alternatives (such as having everyone do their patch against a build from last week and then having an overworked release manager try to assemble them into a working program).

Write tests (2, Informative)

SerialHistorian (565638) | more than 12 years ago | (#3170691)

One of the strategies we use at my company (We also use plain ol' CVS, but we don't have many branches on our development tree) is to team-code and to write tests for every script, so that you can tell if/where a problem has been created by someone else editing a header file. A test should simulate a user using the file/program/script/etc and should double-check the values entered against any values that are stored. By running the testing suite after a file changes, you might still have a merge conflict, but after it's resolved you won't have a bad piece of code.

Extreme Programming (5, Interesting)

Frank Sullivan (2391) | more than 12 years ago | (#3170698)

Check out the development techniques of Extreme Programming (just search Google, silly, and buy a book or three). They have a real solid handle on concurrent rapid development.

The real heart of Extreme Programming is "test-first" programming. The entire development process revolves around unit and integration tests, for extremely fine-grained control over code quality. Any changes that might impact other code should break a test. You fix the stuff that breaks, check in your changes, and move on.

Multiple programmers touching the same C files many times a day sounds like you have either design issues, structural issues, or both. That just should not happen, crunch time or not. Heck, crunch shouldn't happen if you're managing your development correctly.

If you're using cvs, conflicts with source checkins should be very easy to resolve. Even if two programmers touch the same file, they shouldn't be in the same function. If they are, you're back to management and architecture problems, and you need to fix those NOW before work grinds to a complete halt.

Re:Extreme Programming (2)

Lumpish Scholar (17107) | more than 12 years ago | (#3170752)

Extreme Programming doesn't solve this problem; it depends on a solution existing.

(The XP crowd came from a Smalltalk background, and mostly relied on Envy Developer, of which they had many good things to say.)

Re:Extreme Programming (3, Funny)

slickwillie (34689) | more than 12 years ago | (#3170774)

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.

Re:Extreme Programming (1)

Ctrl-Z (28806) | more than 12 years ago | (#3170862)

Maybe you need to find a marketing department that understands that product releases go much more smoothly without "crunch time".

Re:Extreme Programming (2)

pmz (462998) | more than 12 years ago | (#3171002)

I understand that Extreme Programming is comprised of many sound principles...I just wish the name didn't force images of surfers and that Kool-Aid man into my mind.

Anyway, I agree that source files being touched by multiple people at one time can indicate design problems. One thing I've learned is that properly designed software naturally becomes modular enough that several engineers can work together yet not step on each other's code. This also tends to limit the number of engineers that can be applied to a project, but sometimes more engineers just crowd things rather than help. (I thank "The Mythical Man Month" by Fred Brooks for this essential wisdom)

Why are patches applied multiply? (5, Insightful)

Anonymous Coward | more than 12 years ago | (#3170702)

Why in the world should developers be applying the same patch multiple times? You've just said that the problem is not with developers needing to touch the same lines of code -- so, once a patch is in, shouldn't the next person be merging their code with what's already there?
If your problem is with people overwriting the changes that previous submitters made, then you've got a very different kind of mgt problem -- one that can be solved by getting people to use the tools they already have. CVS, for example, lets you merge the current branch head with your working copy, incorporating any changes that may have been made since you checked things out.
Submitters should always diff their current code with the head before commiting a check-in, to see if they are breaking previous changes. This kind of practice is more important when schedules are tight, and you shouldn't let people off the hook because they were in a rush or some other lame excuse.


Source Control + Automated Build & Test (4, Informative)

spullara (119312) | more than 12 years ago | (#3170714)

These are the ingredients to make large projects successful from a technical point of view. At the company I work for, we have literally hundreds of people working in the same source tree using P4 [perforce.com]. It manages merges, versioning, and works flawlessly over the internet (well VPN anyway). It is also much, much faster at syncing to the the depot than CVS because the server keeps track of those files that you are editing and does not need to do diffs with the local filesystem. This is very helpful during crunchtime where you might want to sync serveral times a day (and you have about 10000 files in the system). Also, until your locally edited files are resolved with changes in the depot you cannot submit them, so you don't have the problem of ordering patches properly.

For the second part, I highly reccommend that you have automated build and tests that run after changes have been submitted. You can see how this is done en mass on the mozilla.org [mozilla.org] site. Also, developers should have access to the same build and test infrastructure on their machines so they can do the build and test before they check in their code.

Finally, you need a good bug tracking system. You might try Bugzilla [bugzilla.org].

Good luck,

Re:Source Control + Automated Build & Test (3, Insightful)

Tet (2721) | more than 12 years ago | (#3170796)

Finally, you need a good bug tracking system. You might try Bugzilla.

You might try it, but you'd probably find it lacking. Bugzilla is far from a good bug tracking system. Actually, let me clarify that -- it's a great bug tracking system, if you're tracking bugs in Mozilla. It's horrible for anything else. Data is hardcoded in source files, and if you want to configure it for non-mozilla bug tracking, then you have to edit the source directly. Red Hat and GNOME have obviously put the time in to do so, and have got good results, but for a small business like ours, we couldn't justify the manpower needed to get the system up and running, so we were forced to go with an alternate solution (one I hacked together in PHP one evening -- it may not be pretty, but it works, and gives us 90% of what we need).

Re:Source Control + Automated Build & Test (1)

vinn01 (178295) | more than 12 years ago | (#3171025)

> Data is hardcoded in source files.

Data is in text files. The bugs are in mySQL. A little work with vi and Bugzilla can be customized easily. Bugzilla runs fine without customization. I've installed Bugzilla in a couple hours (providing all the perl and mySQL support is installed first). The report generation is not the wonderful. But for basic bug tracking, Bugzilla rocks.

Perforce and process recommendation (3, Informative)

enkidu (13673) | more than 12 years ago | (#3170928)

Disclaimer: I not an employee of Perforce. I used to be a ClearCase weanie, but now that I've been using Perforce for about a year and a half, I think it's better for several reasons:
  • Smaller. You only need one executable on your client. And one more for your server. No kernel patches, no drivers, no installation, just the binaries. Ubercool.
  • Multi-platform. Perforce has binaries [perforce.com] for practically every platform in use out there. Find me another Version Control System with BeOS, QNX, AIX, SCO, MacOS9 and MacOSX support.
  • Fast, fast fast. Because of the low communication overhead, it works extremely well across slow/high latency links.
  • Ease of use. It's really easy to configure and setup.
  • Great support. We've had to go to perforce support twice and both times they've been awesome, with quick responses and knowledgeable people.
  • Price. The single server, two client setup is FREE! And per seat licensing + support is very very reasonable. I use the free one on my laptop to version files.
  • Plug-ins. Perforce publishes their API, and they have perl, python, ruby and tcl utilities [perforce.com] galore.
Now my process recommendation. If you have paid for ClearCase then pay for some more education. ClearCase/Perforce can do lots of what you need automatically. You should practically NEVER have to repeat the same change on a file. You may want to look at some branching/merging techniques which can eliminate the need for colliding checkin's also. Rational has a bunch of whitepapers [rational.com] up on their site, as does Perforce [perforce.com].

Most of all, I would advise you to educate yourself on the options/methods of version control. 12 isn't that big. Wait 'til you get to 1200.

One more thing: atomic operations. (2)

enkidu (13673) | more than 12 years ago | (#3170985)

Perforce has them, ClearCase and CVS doesn't. You can check in a list of changed files as one atomic operation and it either succeeds or doesn't. So you can't get a partial check in which breaks the build. This is a totally kickass feature which has saved my bacon a couple of times.

nerdz (0)

Anonymous Coward | more than 12 years ago | (#3170720)

nerdz...developerz...anyone reading or partipating in this discussion needs to seriously get laid!!!! gpl this, cvs that, what the f#*$ ever, get a damn life!!!

What about . (1)

mryken (101540) | more than 12 years ago | (#3170721)

I admit I haven't programmed part of a big project, so I haven't really experienced the issue at hand. But assuming different parts of the same file are what is being modified concurrently, what about using tags for the different logical parts of the file. So if I modified "ThisFunction" and someone else modified "ThatFunction" they could be tagged as ... and so on. Then, when it is checked in changes made withing those tags are taken and put in a central copy of the file.

Perhaps is too simplistic or just way off base, but that's my thought.

I think all spammers should be jailed (0)

Anonymous Coward | more than 12 years ago | (#3170731)

No really, I do. Check it out. Just because
you think you are too cool for words and
give out your email address to any webpage that
asks for it makes you immune from spam well hoss
just forget it. What is the topic of the story
I'm replying to? I forget!

CC (1)

kippy (416183) | more than 12 years ago | (#3170733)

I'm a ClearCase admin at a big company. I might be biased but I think it'll handle everything you're worried about. CC can already keep track of who's doing what and when. Branches keep track of the "who" and CC keeps loads of metadata to account for the "when" amongst other things.

One thing you can do if you really want to keep things straight is to write a trigger that writes "who" and "when" and anything else to a log file whenever someone does a checkin.

Re:CC (2)

renehollan (138013) | more than 12 years ago | (#3170768)

This fails if you have multiple incompatible semantic changes to the same file in different branches which then merge.

No, this shouldn't happen with disciplined developers.

Yes, it happens: not all developers are disciplined.

Patch/Tree Manager and/or per-developer branches. (2, Interesting)

jordan (17131) | more than 12 years ago | (#3170742)

This is a common problem most easily managed by a human, not automated tools like CVS. On a per-tree, per-branch or even per-module basis, each chunk has a person responsible for managing changes to the tree, which I traditionally call the "Patch Master". This alleviates the common problem of multiple patches wiping each other out, as described.

Patches are either sent directly to the patch master, diff'd against a base or branch, or are committed on a per-developer branch, after which the patch master is notified either by built-in CVS mechanism or email. In both cases, it is the Patch Master's responsibility to merge changes from diff or from branches. Merging is a tedious process, but this alleviates the productivity problems affecting everyone on the devteam, limiting it to just one person and allowing everyone else to progress with further development.

Some people complain that having one person manage patches does not scale (i.e. "Linus does not scale"), but what I'm suggesting is a more collaborative, distributed, team-oriented approach -- perhaps you have a team of 10 developers with 5 "modules" in active development; each module is assigned a "team lead" as patch master and they are responsible for managing commits.


This sounds like an architecture problem (3, Insightful)

McMuffin Man (21896) | more than 12 years ago | (#3170743)

I manage a somewhat larger project (35 developers at two sites), and we have very few issues of the type you describe, despite aggressive development schedules. The key is in architecture and planning. If developers are really performing tasks so different from each other that they aren't already in close communication with one another, you need to ask yourself how they happen to be working in the same source file. With proper architecture and modularization, discrete tasks will naturally land in different parts of your source tree.

There will always be some cases where there's a little overlap, but if your architecture makes these overlaps rare, it becomes relatively easy to see them coming when you lay out your schedule and plan around them.

CVS or BitKeeper (1)

gbr (31010) | more than 12 years ago | (#3170746)

I'm really surprised that CVS doesn't work for you. I've used it on single person and 15+ person projects, and we never had situations where people had to re-apply their work.

The only thing that I wish CVS had is transactional based updates. That is, either all check-ins work, or they all fail, as a single transaction. And that transaction logs (all files that are part of a check in are remembered as a group, rather than as individual checkins).

Sounds like no one is in charge (1, Insightful)

Anonymous Coward | more than 12 years ago | (#3170751)

And no one is doing CM correctly, either.

And 12 developers isn't large at all. 400, that's large.

The simple fix? Back out any check in that fails a merge or fails to compile, and publicize it!

"Ha ha! You broke the baseline again" is a wonderful motivator for doing your fucking job correctly!

It will only happen once or twice to your good programmers before they learn, and if you piss off those who don't learn and they quit on you, do you really want programmers around who are continually breaking your baseline product?

Product Management and Strong Architecture (5, Interesting)

dant (25668) | more than 12 years ago | (#3170760)

Yikes! You have the process problems of a group five times your size.

If you have several people changing the same file in a given day, then one of two things (probably both) is wrong:

  • Coordination between features/projects. Somebody should be keeping an eye on the list of fixes/enhancements that are coming down the line and making sure you don't get too many in the same neck of the woods. This person doesn't necessarily have to be a developer (but should be able to speak developerese), and their whole job is to tell people, 'No, I'm sorry, but there's no room in the schedule for feature X that you want. Can I interest you in feature Y, which is in a different part of the code?'

    Also, if your code is fairly big (more than a few hundred thousand lines), you need to break it into logical chunks and assign somebody to watch every checkin to each chunk. That person is a developer and responsible for making sure new code gets reviewed and unexpected changes aren't being made. If your code is smaller, one person can probably do that.

  • Code Architecture. If several functionally-unrelated features end up needing to change the same file, then something is wrong with that file. There's too much going on in it--you've got to be dilligent about keeping your components small and keeping each component in a separate file. See the excellent Lakos book [barnesandnoble.com] for tips on how and why to do that.
Most likely, your organization went way too fast at some point in the course of setting up the core code architecture and the processes by which you decide what does and does not go into a release. You need to get started fixing both--or this problem will keep getting worse and worse until you're unable to move forward through your own inertia.

.2 cents (2, Insightful)

ZeroConcept (196261) | more than 12 years ago | (#3170761)

My experiences on a 80ppl project:

1) Minimize dependencies through refactoring.
2) Try to avoid branching as much as possible.
3) If branch, minimize the lifetime of it.
4) Before merging back a branch into the main, merge the main to your branch, recompile, test and then merge back.

Just some thougths...

air traffic control requires a controller (1)

ethereal (13958) | more than 12 years ago | (#3170775)

I agree with some of the other comments about how the fact that you've ended up in such a situation probably means that some things weren't planned right to begin with.

However, since you've still got to dig out of the hole that you're currently in, I think you're sort-of on the right track. The problem with bringing in a bunch of changes at once is twofold: you have to do the merges properly, and you also have to ensure that bringing in developer A's changes doesn't break what developer B just did.

To get the merges done properly, your best bet is to stick with your current air traffic control strategy, but make sure that you have a controller who runs the show and does the merges. You need someone experienced enough that they can merge most people's code without breaking it, even if they don't quite understand all of how it works. Devoting a person full-time or almost full-time to merging at crunch time would mean that developers can focus more fully on making the right fixes, testing them, and making them easier for you to merge.

As far as verifying that your merges haven't broken something else, probably your best bet is to test rigorously with each new release via automated tests. This is going to be a pain to set up right now if you haven't planned for this, but there's really no other good solution. You can also try to enforce peer review for changes, on the hopes that developer B will notice that developer A's changes will break something that B just fixed, but peer review doesn't always catch everything, especially at crunch time.

I think you've pointed out an interesting failure of current SCM tools - they make it fairly easy to keep things organized, but they trade off speed for that organizing power. I don't think we have very good tools yet that will allow you both speed and organizational power.

Sequence number solution fatally flawed (2)

Frank Sullivan (2391) | more than 12 years ago | (#3170782)

Sorry, but that's a TERRIBLE idea. Things will always happen out of order. The best baseline is a fresh cvs checkout. Programmers are responsible for not checking things in until they know it doesn't break anything. How do they know it doesn't break anything? All the tests pass. Where do the tests come from? (Wahwahwah, we're too busy coding to write tests!) You write tests BEFORE you write code. When you write the test, it's broken. Then you fix it. It works.

Another useful Extreme Programming idea is "stories". Programmers work on problems small enough that they can fit on a notecard. If it won't fit on a notecard, break it into smaller problems that will. Pretty soon, you have a huge stack of "stories". Sit down with your customer and triage them. Release early, release often, and the code is ALWAYS correct. Or at least all the tests run, which is more than can be said for 99% of all the code out there.

Methodologies and Tools (2, Informative)

soap.xml (469053) | more than 12 years ago | (#3170788)

We use a couple of methodologies in my work place. Granted we are a Java shop so some of this stuff doesn't apply across the board, but the concepts work for almost any language/development platform.

First, XP Style testing. Test first, and test often. Write a test case for every class you make, test everything, unit test, regression test, integration test you name it just TEST it.

Second, simplify your development process. There really should not be the need for multiple people to be working in the same file/class/header etc... Assing pieces of the project to different developers and model it out, have them work in there rescpective pieces, if you MUST assign multiple people to the same header, thats okay, but make sure they work together closely to not step on each others toes. This is really a planning issue.

Third, I assume you are following a build process (nightly, weekly etc..), we use Ant [apache.org] to help with this. Granted it doesn't help for the problems of developers stepping on each other during the day. But it forces everybody to check in there code and make sure it works, everyday (we use nightly builds).

Okay with all of this stuff, we rarly EVER have problems. Our code is usually close to bullet proof (the constant testing), each developer really knows the portions of the code they worked on, and can quickly make fixes if needed (the simplification of the development process), and we are constantly aware of our timeline and progress (nightly / weekly builds).

Anyways, thats just how we do it ;)


black box (1)

beauzo (566782) | more than 12 years ago | (#3170789)

For example changing headers that two developers need... The only headers that two groups need should be interface headers, these should be set early and not need a lot of change, with any change taking both developers changing the code internally... I work on a core technology team whom are all very experienced programmers originating from many different software universes (embedded, games, DB, etc). Based on the evil of past experiences, we set out to develop the interface system before starting *any* actual project (or projects). This took a little over a year of design and development evolution with no actual product releases (some protos). In spite of such a long "generation" process it took us only 3 months to release (spit out) one particular product... I truely believe in taking time to dream and design--construction is the easy part.

patch code monkey (2)

josepha48 (13953) | more than 12 years ago | (#3170791)

It would seem to me that you would need a patch code monkey. Someone to review the patches before they are applied to make sure that two people do not over patch each other.

When I worked with CVS I always had problems of people overwriting my changes or incompatible changes.

In the Linux world there are usually modules maintainers. Often only one maintainer is responsible for the ci/co of the source tree and more often people pick a branch to work on then port their stuff to the branch it gets checked in to.

The Linux kernel does not use CVS, right now they are moving to (or moved) bit keeper.

Where I work we use a custom program that does locking so that only one person can work on a file at a time and this eliminates all conflicts. PVCS also does this and run under both Windows and various UNIX flavors. Locking is not as bad as it may sound and in fact it is good in the case where you have several files that are frequently accessed.

CVS is good when you have less bumping heads. Of course this has been my experience, others may have other opinions.

One thing you could do is build a small program layer on top of cvs, or maybe some scripts to do some locking so that people are less likely to bump heads.

What you are doing isn't concurrent development! (4, Insightful)

Kaz Kylheku (1484) | more than 12 years ago | (#3170805)

The reason it isn't concurrent is because you have people separately working on patches, but those patches are dependend on one another, so their ordering matters. When ordering matters, the situation is sequential, not parallel. The whole bit about air traffic control and sequence numbers is about serializing the parallel development.

The trick is to decompose the development task into chunks that are in fact parallelizable. In turn, those chunks may have sub-chunks which are not parallelizable; those chunks should be perhaps done by one developer, in the correct order.

No developer should wait around for another's patch, and nobody should develop anything that he or she knows will soon be invalidated by a forthcoming patch so badly that it will have to be substantially reworked. If a unit of work depends on some forthcoming patch so badly, a developer should find something else to work on until that patch arrives. How you know that the patch has arrived is by monitoring your e-mail, or scanning the version control system for changes. The other developers should know that someone is waiting for their patch in order to do the next, dependent part of the change, and broadcast it to the team when they are done.

Clearcase branches (2, Interesting)

VictimlessChris (562438) | more than 12 years ago | (#3170810)

I work with a number of other software developers on a fairly large project where things are constantly changing. We currently use Clearcase. To avoid multiple submissions in order to have changes accepted once, each developer has their own branch, which is a copy of the main one. Developers work in their branch changing files until they feel they're ready to sumbit changes to the baseline. They merge the current baseline into their branch, grabbing all changes so far, and then merge back into the main branch. This effectively checks out the files, so only one person can make and submit changes at a time.

Division of ownership/responsibility (4, Insightful)

PureFiction (10256) | more than 12 years ago | (#3170812)

I worked on a large project (20+ developers) where this situation occured from time to time. There were specific interdependencies between some sources files for various parts of the development effort, and it was easy to step on other peoples feet unless specific steps were taken to prevent this.

Before I describe how we handled this situation, I want to stress the fact that if someone intelligently devides the labor according to how the changes will affect other parts of the code, the need for developers to sqabble over specific changes in specific files should be eliminated.

Labor should be devided at well defined "interface points" where the additions/changes to the interface can be done quickly, satisfying the needs of other developers requiring those interfaces to build against, and then completion of the underlying code can be done with little interference or effect on others.

In short, devide work along interface boundaries, and stub out interfaces with enough code to allow compiling, while developer(s) continue to actually implement the code behind the scenes. Thus, swapping in the actual code has no effect on any one else code, exept that the stubs are now full implementations and work correctly.

Ok, so what happens if the devision isnt clean and you have two people working on the same file?

NOTE: When I am talking about file granularity, or developers "owning" specific files, you can also substiture "subsystem", etc. Sometimes developers are working in entirely different areas of the source tree for the most part, and it makes sense to assign an entire sub tree to a specific developer. This is the devision by interface, which is the usual case.

What we did was assign specific files to specific developers, who have the most work to add/modify to the file. When other developers require changes to a file "owned" by another, they perform the merge, which is verified by both sides to work correctly, and then it is checked in by the "owner".

This was all accomplished using locks (file checked out, ClearCase) and multiple views. The locking of files was a benifit, as it prevented accidental overwrites of other peoples code. Once you check out a file and lock it, no one else (short of the administrator) can check in a modified version and clobber your changes.

A short scenario:

Alice: owns file/tree "something.cpp"
Bob: owns file/tree "modified.cpp"

Tree is something like this:

|-- Devel
|-- AliceView ---- BobView
| |
[code] [code]

Alice and Bob are both working in a development branch. Alice has the files she is modifying and "owns" checked out and locked. Same for bob.

Bob realizes he needs to make changes to "something.cpp" to support some changes he is making in "modified.cpp".

He checks out a temporary version, unlocked, of "something.cpp" and makes the required changes.

He then notifies alice of the changes, and using the automated merge features she adds his changes, manually resolving conflicts if necessary.

Bob changes his view to use Alice's version of the file with the rest of the code from his view. He builds and verifies that everything is working correctly. Once this is verified, Alice can check in the changes, and Bob can now use the most recently committed version and continue on his merry way.

What this boils down to is basically enforcing ownership through locks to prevent accidental overwrites of others code, and defining clear lines of ownership so that a change is only accepted and merged when the person responsible for that code has tested it (in addition to the developer desiring his minor modifications be included)

On CVS and Clearcase (5, Informative)

ajs (35943) | more than 12 years ago | (#3170817)

I've admined both extensively, and I can make a couple of comments here. First, Clearcase is licensed software. Understand that when you get locked out because all of the licenses are in use, you cannot touch your source-code (though someone with a license can copy it into a sandbox for you). Also, Clearcase is a resource pig. It wants a pretty beefy central machine to run on, and if lots of people compile at the same time, the virtual filesystem is not very efficient.

Now on to CVS. CVS is most everything you want from revision control. It's biggest shortcomings are in branch management and the ease with which changes can be made incorrectly. Its ability to interface with well known and standard protocols like rsh, ssh and gzip (which is a format more than a protocol) make it painful to move to anything that's overly proprietary. Its use of your local diff is wonderful ("cvs diff -u" was a revelation for me).

Clearcase manages branches better and can handle non-realtime latency in updates (e.g. you can have two Clearcase repositories at different sites and you can connect them by mailing tapes around or by dialing up once a day). This can be invaluable when you're working in high-security environments, but is otherwise mostly a moot point.

Clearcase has improved in the last few years. They've added some local-checkout features where you don't have to work off of the virtual filesystem, and that helps.

Overall, I'd say CVS is the better system, but Clearcase will sometimes get jammed down your throat, and there are definitely worse fates than to have to get your project working under it.

Not generally a problem with Open Source... (1)

sultanoslack (320583) | more than 12 years ago | (#3170821)

I've never heard of a project where the ratio of code to developers was such that they were always touching the same things at once. Sure it happens infrequently, but not enough to really worry about it. It seems that OSS projects tend to be a few people working really hard on a lot of code. i.e. 50,000 lines of code in 100 files and 5 developers.

It sounds like you may need to make your projects more atomic if you're having problems like this. Make classes (or whatever organazational unit that you're using) smaller and put less in files. Finalize APIs for components to work together and tell people not to touch what itsn't theirs.

Assign a maintainer to each portion of your code and make it such that if others want to change that, they have to send patches to the maintainer.

There are lots of ways around this, they just require better organazation than Ok, everybody make everything work!

your developers need to communicate (2)

markj02 (544487) | more than 12 years ago | (#3170826)

If you have multiple developers creating conflicting patches, they are working on the same part of the code and they need to coordinate and communicate. There is nothing that CVS or any other version control system can do about that.

How they communicate is a separate issue. IRC works for some projects; IM is another choice. CVS also offers file-level locking and that can be used to communicate that someone is preparing a patch for a file, but it requires planning ahead and splitting up files.

Design, design, design! (2, Interesting)

feloneous cat (564318) | more than 12 years ago | (#3170837)

Oh, did I mention design?

Most companies find (the ones that actually DO it rather than pay lip service to it) that designing a project PREVENTS the "patches on patches".

Another thing that many people say they do (but rarely do) is actually have meetings that accomplish REAL goals rather than perceived ones. I have been in "design" meetings that were merely CYA meetings - nothing was designed and it was all a waste of time. On the other hand, I have been in meetings that I was invited to (but really had no business being in) that actually SOLVED problems a) BEFORE they happened or b) reworked the nature of the beast so that it was not nearly so intractable design.

Communication. Not just CYA, but actually TALKING and LISTENING (you wouldn't believe the number of software engineers that just will talk and talk and never hear a damn thing).

Making it a death penalty to break someones locks helps too...

Just use CVS ... (0)

Anonymous Coward | more than 12 years ago | (#3170842)

even if if think i know who sent this message to make free advertising on it's product, CVS is still the better choice for standard development ...

Why not make the coding realtime? (2)

HanzoSan (251665) | more than 12 years ago | (#3170846)

Meaning let the user see realtime results instead of through the web.

An IDE interface which is sorta like IRC or something

Re:Why not make the coding realtime? (1)

Mulletroll (544539) | more than 12 years ago | (#3170929)

I have thought about this before. It could probably be done in emacs lisp, if it hasn't been done already. Like pair programming, but over a network.

I don't think it would scale well though.

Maybe the software is not the problem (1)

Ctrl-Z (28806) | more than 12 years ago | (#3170847)

Where I work, we have ~15 developers working on a web-based application. There are never any problems with multiple developers working on the same code at the same time. Why? We have a policy whereby all checkouts are exclusive, and there are no merges. That way, you get in, change the file you need to change, and then check it back in again.

This may not work for everyone, but if you modularize your code it really isn't that bad. Heck, we use Visual SourceSafe, which has to be the crappiest revision control system on the planet, but we can still make it work.

Sigh - it's not CVS/CC/SourceForge (0)

Anonymous Coward | more than 12 years ago | (#3170849)

those are the TOOLS.

Your problem is in the PROCESS.

Your developers aren't checking the tip revision when it's crunch time.

  1. Lock file (keep others from changing it)
  2. check out file (get a fresh copy of it)
  3. add your changes to THIS file (so nobody's other stuff goes by-by)
  4. check this new file back in
  5. unlock file (allow others to use it)

I STRONGLY recommend using a $LOG$ feature (if it's supported) where the software adds to the code who checked out a file and whatever comments were added to the file. (It will help in identifying who's blowing away other's fixes).

Re:Sigh - it's not CVS/CC/SourceForge (1)

ohios (558312) | more than 12 years ago | (#3171035)

That process is a little too simple - it assumes your changes are in only one file. What source control needs to let you do is lock out a set of files so your changes to many files can be checked back in as a transaction.

It should help you remember what you've checked out so that you don't forget one file and go off for a coffee/holiday and screw the build up. The transaction could even include a ticket number for the bug/project line you are working on etc.

Haven't used CVS for a while but I don't think it helps you do that - and I'm pretty sure clearcase does, but it seems to be an art in itself...

The correct way to use CVS (2, Insightful)

jschmerge (228731) | more than 12 years ago | (#3170851)

CVS is more than adequate for development on small to mid-scale projects. There are several things that you need to keep in mind, however.

  • Make it a policy that developers must do a 'cvs update' before they commit any changes.
  • CVS is not a backup system for your work. Consequently, have developers only commit changes that are complete; do not check in changes that will break existing code.
  • If a developer is making wide sweeping changes and/or rewriting a major portion of the program/project do it on a branch
  • Have someone become the dedicated CVS administrator for a project. This person is the only one allowed to tag releases and manage the integration of developer branches with the main development trunk.
  • Enforce a policy that code commited to CVS must build. I once worked for a company that enforced this rule by setting a policy that the first person to commit broken code each week had to buy the rest of us a case of beer Friday afternoons.

As a side note, problems with header file commits late in the development stage of a project is more likely do to poor planning and design than to the configuration management tools you use. C header files are used to specify interfaces to various modules of a program and should not change late in development, this indicates either a deficient or non-existent design.

Use a transaction oriented vers. sys. and hire a.. (3, Insightful)

dgerman (78602) | more than 12 years ago | (#3170855)

You need to:

1. Create as granular files as possible. If a C file is often modified by more than people, then split that file into 2 files.

2. Use a transaction oriented versioning system (such as IBM's CMVC). CVS is not up to the task of larger organizations with plenty of concurrent development in the same files. You need to be able to roll back an entire transaction, not only a file change! CMVC provides the notion of transaction, either the patch happens, or it does not happen. It also allows you to lock the files when you are ready to commit.

3. Hire a person to take care of the build. It is cheaper to hire somebody than having your developers wasting time doing it. The build manager will be responsible for serialization
and rejection of atomic patches. Somebody can
still brake the build, but your developers
don't have to worry about it (only the breaker, who will have the builder's finger pointing at him and get the shame!)

4. Accept that manual merging is a matter of life. Merging offers also the chance to do code inspection, which is a good thing.

CVS usage (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3170897)

Isn't that what CVS is for? Keeping a single writable copy checked out...seems to me you made your bed by allowing counter-productive functionality to exist in the system, now you get to lie in it.

Maybe I've been using something else called CVS all these years. Maybe you should find that?

What we did (1)

raju99 (181013) | more than 12 years ago | (#3170906)

I was architect for a project with a team of 25 folks. 15 in Hyderabad, India and 10 in Boston. We used StarTeam as the source repository. I have to say it kicks ass!!!

Starteam has got a built in bug tracking system, provides extended support for build labels, branching etc. They provide two clients (1) Windows client (2) Web client (HTML, Javascript etc.). So basically, the server can be configured to listen on port xxxx or can be accessed by a web server which will run the web client.

The downside to it is that it has piss-poor diff-merge tools. But we used Araxis (which really really kicks ass) for merging files.

This setup and some basic procedures let us do continuous builds without too much of a headache.

Cheap Marketing Ploy by VA Software? (3, Funny)

ONU CS Geek (323473) | more than 12 years ago | (#3170909)

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.

Perforce! (2)

Boone^ (151057) | more than 12 years ago | (#3170912)

At work we use Perforce [perforce.com] as our revision control system for verilog ASIC designs. It requires you to explicitly "check out" a file to edit it, and if you attempt to check out a file while someone else has it out, it warns you. It's got a great setup system that allows you to add certain directories to your "view" (like, I'm only concerned with the verilog from the ASIC(s) I work with, and not any of the others) without seperating everything out into different projects. It's got auto-merge abilities, as well as warnings at check-in if there's conflicts with lines. You're not allowed to check in a file that hasn't been properly merged, either manually or automatically.

Perforce has a daemon that is run, and it's got clients for Windows and all the Unix clones, free and non-free.

Now, perforce itself isn't free, but some things are just worth the money.

Locking files (1)

spludge (99050) | more than 12 years ago | (#3170914)

I have a question? What is wrong with using a system where a file is locked when it is checked out and nobody else can edit it?

I have used sourcesafe for about 3 years now, it uses this menthod, and it has always worked out pretty well (although there are some issues with databse corruption when projects get very large!). It really forces discipline, if you don't checkin your code as soon as you are done then other developers will complain. You might think that you lose some flexibility here because two developers cannot work on the same file at the same time, in practice though we have found that there is very little loss. If another developer is working on a file then there is always something else that you can do on another part of the source until they are finished. Not having merge problems or anything like that is a pain.

Does anyone know of any good open source solutions that allow for this type of source management? Sourcesafe may work ok but it is far out of date now

People have to trust the system (2, Insightful)

eison (56778) | more than 12 years ago | (#3170923)

Everyone needs to stay up to date all the time.

If you have a regular (hourly/daily) build that smoke-tests and reports the results to everyone, people will be more willing to sync to the latest and trust that they won't lose lots of time with problems. Embarass anyone that breaks the build, make sure that everyone understands it gets fixed ASAP when it breaks, checking in broken code is NOT ok; and then people can sync every few hours or every day, and the problem simply goes away.

If this is a problem, your methodology is broken. (1)

ProtonMotiveForce (267027) | more than 12 years ago | (#3170988)

Learn to use OO (or any other methodology which lets you segment code based on likelihood of change). e.g. in Java you do your analysis and design, and your interfaces are more or less 'set'. Then you just code the implementations, and you don't generally tromp all over eachother nearly as much.

managed branching and merging (2, Informative)

tjuricek (514513) | more than 12 years ago | (#3170994)

(My screen got jumbled... i hope this isn't a duplicate post.)

My job has been to create a version control system that solves exactly this problem and automates others. Right now, it uses CVS, but is based off of a system that used PVCS and ClearCase.

Our revision system starts with release labels. Each directory gets tagged to a particular release label. Baselines, then are groups of release labels.

When a developer releases, their changes are branched off of the release label the directory started at. Then, the latest release is merged into their changes (if a later release from the one the branch is based off of occured). If everything still checks out, the branch is merged to the main development tree.

We have two scripts that make this process very simple: a commit and a release. The commit will take the current directory and create a users branch. This is for moving between trees - the developer now has a sandbox label they can update to. The release, which calls commit to make the user branch, handles both passes of merging.

I've noticed that CVS is not the greatest system for handling branches. It's ability to detect common ancestors is, well, flaky. I'm eagerly awaiting the release of Subversion, since my company really doesn't have the ooodles of $$ for ClearCase.

Also, note that when a developer releases, we also collect information which can link this release to a bug tracking slip. We also collate the release notes for releases. Ergo, you want to make a patch for your product, it's easy to collect all of the notes of changes and then create a single ChangeLog (which you usually want to edit a bit).

The system actually has been extended to handle multiple streams of development. This allows us to bugfix released versions of the product while making later changes, and smoothing the bugfix integration between releases. Adding this feature is both an enormously complex task and a huge timesaver for a large development team. You'd definitely push the bounds of what CVS can handle at this point.

Just some thoughts. This isn't a simple issue, but can have a solution that is simple to use.


General Suggestions (4, Insightful)

MidKnight (19766) | more than 12 years ago | (#3171003)

I'm not going to suggest which source code tool to use, or how to organize your projects. But here's the short version of a few general suggestions that might help:

  • Do the planning. This is the most difficult stage because (as was mathematically proven last year... where is that link?) it is impossible to estimate the complexity of a computer project. So, your plan should be reasonably flexible, but still stick to a concrete form. Oh, and don't call it a schedule! Most managers don't have the self-control (or technical expertise) necessary to grasp the fact that computer project "schedules" are at best a shot in the dark.

  • Set written-in-stone dates to re-evaluate the validity of your plan. It isn't an admission of failure if, half-way through the project, you realize your original plans were ass-backwards :) If it were easy, everyone would do it.

  • Whatever source control package you use, try to avoid the "One Parent Tree, 200 children" syndrome. Any project will have reasonably logical groupings of tasks. Each sub-group of developers working on those tasks should first consolidate their changes into their own sub-tree, and then consolidate with the main tree. 3 or 4 levels of parent-child trees can help break down the pain of file merging.

  • Most development groups have some type of a code review process before the code goes back to a shared source tree. Improving on that, I've had some success at requiring two code reviews: one for code correctness, and one for its impact on the build process. These two reviews should never be done by the same person (or group).

That's the a few points that I've found to be helpful in my professional work. Your mileage may vary.

Good luck,


LARGE? (2)

MosesJones (55544) | more than 12 years ago | (#3171020)

The Largest project I worked on was when I was leader of a team of 6 people, which was in a team of 20 people, in a sub-project of 100 people, in a project of 1,000 people. And that was just development.

Tools are great, but for large projects the hammer rules.... don't know the hammer ? The hammer says "Fuck up the build, I nail your testicals to the floor, fuck up the release and I nail your eye-lids to your testicals first."
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account