Tips on Managing Concurrent Development?

nice acronym by Void_of_light · 2002-03-15 10:15 · Score: 1, Informative

mofo I like it

Fly by the seat of your pants. by ramdac · 2002-03-15 10:17 · Score: 3, Funny

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. by b0r0din · 2002-03-15 10:55 · Score: 1, Funny

So you know when the next version of Windows is coming out?
Re:Fly by the seat of your pants. by kanotspell · 2002-03-15 11:10 · Score: 1

now THAT'S funny
Re:Fly by the seat of your pants. by Anonymous Coward · 2002-03-15 11:14 · Score: 0, Insightful

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^(
Re:Fly by the seat of your pants. by addaon · 2002-03-15 15:23 · Score: 2

I normally have no more respect for slashdot moderation than anyone else... but dude, it's time to be scared when your development practices are modded as funny!

--

I've had this sig for three days.

Tips on widening pages! by Klerck · 2002-03-15 10:17 · Score: 0, Insightful

SourceForge 3.0 Enterprise Edition by Anonymous Coward · 2002-03-15 10:18 · Score: 4, Informative

(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 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, you don't know what you're missing.

Re:SourceForge 3.0 Enterprise Edition by Anonymous Coward · 2002-03-15 10:35 · Score: 0, Funny

Fuck off Taco, log in next time.
Re:SourceForge 3.0 Enterprise Edition by Anonymous Coward · 2002-03-15 11:13 · Score: 0

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 by Anonymous Coward · 2002-03-15 11:21 · Score: 0

You've obviously never worked on a large or even a medium size project.
Re:SourceForge 3.0 Enterprise Edition by sourcehunter · 2002-03-15 11:58 · Score: 3, Informative

Problem with SF EE:

Minimum user license is 30 users, and that is roughly $30,000!!!

I run a small development firm and I wanted to use the enterprise edition. I'll pay a few thousand for something, but $30k for 30 people? I think not.

--

quis custodiet ipsos custodes - Juvenal
Re:SourceForge 3.0 Enterprise Edition by Electrum · 2002-03-15 13:00 · Score: 3, Insightful

I run a small development firm and I wanted to use the enterprise edition. I'll pay a few thousand for something, but $30k for 30 people? I think not.
While I can't say the SourceForge is decent (imho looks like a hodgepodge of thrown together junk), $30k for 30 people is not really a lot. Say salary, benefits, overhead, etc., cost you $1k per week per employee (which is likely very modest). Is something like this going to save each developer a week of time? If there's a tool that good, then it's well worth the money. Sure, it's a big one time cost, but even over the course of a year, it really does pay for itself.
Re:SourceForge 3.0 Enterprise Edition by xtremex · 2002-03-15 13:41 · Score: 2

My old company used something called PVCS made by Meranth. I never used it personannally for code keeping, however I have set it up, and it seems very similar to CVS with a graphical shell built in as well. But, you could always use the GUI CVS clients (TkCVS and Wincvs for Windows)

--
If you're not a Liberal in your 20's, then you have no heart.If you're still a Liberal in your 30's you have no brain.
Re:SourceForge 3.0 Enterprise Edition by tenman · 2002-03-15 14:38 · Score: 2

spoken like someone who know the value of CMS vs. VCS
Re:SourceForge 3.0 Enterprise Edition by Malcontent · 2002-03-15 18:19 · Score: 2

1) Install debian
2) apt-get install sourceforge.
3) Do a bit of fiddling (well maybe more then a bit).
4) save 30K.

--
War is necrophilia.
Re:SourceForge 3.0 Enterprise Edition by Malcontent · 2002-03-15 18:22 · Score: 2

I thought SF was open source? When did it become proprietary? Oh yes when VA locked it up.

--
War is necrophilia.
Re:SourceForge 3.0 Enterprise Edition by tedric · 2002-03-15 22:33 · Score: 1

It might be the best, but the license model is way too expensive. And that sf-genericinst/debian-sf/alexandria stuff is a mess to install just to evaluate the software. Will there ever be an open source edition of SF? I'm monitoring the forums at SF.net but there's not much traffic there.

There are some other products out there like CodeBeamer, SourceCast, TeamSource, etc. It seems most of them are hosted services and you can't get a copy to install it inside your company (which is a requirement for my company).

What we need is:

- project homepage
- bug tracking
- task & patch management
- discussion forums
- document sharing
- CVS
- context collaboration
- project administration
- user administration
- SSL
- code-browsing
- QA
- dependency analysis
- impact analysis
- cross-referencing
- reports (HTML, ASCII, Excel/Word or StarOffice, LaTeX would be nice, too)

As mentioned above, the SF 3.0 Enterprise Edition license keeps us away from SF. Maybe it's time to join the open source projects based on SF 2.5 - the software is a nightmare. And why is it coded so database dependent? I'm not willing to install and maintain an extra PostgreSQL or Oracle DB just for SF while all our 3000 developers use DB2. I know, DB2 support is announced for this year, but I need a CDP this (better last) month. There are deadlines out here in the real world and not much time to play around with software that should help your developers with collaboration instead of being an issue itself.

BitKeeper is the answer by georgn · 2002-03-15 10:18 · Score: 1

http://www.bitkeeper.com/

I recommend SourceForge OnSite (c) by Anomolous+Cow+Herd · 2002-03-15 10:19 · Score: 3, Interesting

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!

--

"I don't know that atheists should be considered citizens, nor should they be considered patriots." - George Bush

Re:I recommend SourceForge OnSite (c) by Anonymous Coward · 2002-03-15 10:25 · Score: 1, Informative

The above may be a shameless plug, (+ some anti-MS FUD) but I do agree SourceForge is the best I've seen so far.
Re:I recommend SourceForge OnSite (c) by BlowCat · 2002-03-15 12:24 · Score: 2

No, it's shameless karma whoring. Note complete lack of serious arguments and links to the benchmarks. Note that the Microsoft's product (Visual Source Safe?) is not called by name.
This comment is a perfect example why Slashdot comments should not be trusted any more than a spam that promises you penis enlargement and millions of dollars.
Re:I recommend SourceForge OnSite (c) by tenman · 2002-03-15 14:33 · Score: 2

Please, stop it already!!!!

I realize that 12 programmers writing code 80 hours a week, on one product is a nifty challenge for a tool as robust as OnSite , but honestly (and I'm not saying this in some sort of 'my crank if bigger than yours' type of way, as I'm sure to you your project is very intense) it's the same as some rich executive that hasn't used a computer sense the 70's saying 512k of RAM is all anyone will ever need.

If you plan on having really well done configuration management, you need a configuration management tool. ClearCase, Continuus/CM Synergy, PVCS (to some extent) are what you are looking for. I'm not advocating any of these, and I have a cheaper alternative I'll talk about later. If you're wondering, I am a CM administrator (thus my viewpoint may be a little more relevant than that of a manager who doesn't know how the tools works.) The original question was about concurrent development, and as such, doesn't deal at all with versioning, but more along the lines of lifecycle. Any one who has ever stepped out side of a VCS environment and into an actual CM environment can tell you about how a well planned life cycle can save your developers hours and hours of headaches just like the ones that you are dealing with now.

This is one field of software, where once your into it ($500k - $750k when you figure in man hours and software and hardware) it really hard to get out and put yourself into another system. We just moved from Continuus and the cost to get into that CM Tool was (after the accounting geek figured it) was almost 4 million. You have to think about things like rewriting code, and restructuring directories, and while your developers are doing that, they are not developing new code, and that costs the company money too. I say that to tell you that this was a massive project. We moved 14 products, 12 development teams, 1.24 million files (and that was without previous versions for history), and all from a home brew version control system on top of rcs. We were happy a penguins on a screensaver, when our company made us move to a CM(ish) tool of it's own again. (ooohhhh the joys of being acquired). The new relocation cost? 4 million.

If you want a really nice tool, you have to pay for it. There are no freebies out there. Save one. Perforce has a tool that is almost as robust as the big guys with out the fuss of four digit per user licensing fees. It's not free to use commercially, but they offer great deals for small shops, and OSD. And even the commercial licenses are not blown out of proportion that badly.

If you really want to do concurrent development (or parallel development, PD, as its called by professional grade tools) you need to invest in one of the big three, or the little CM tool that could. If you have a good life cycle and a tool that was built to handle PD, you will not have to post your CM questions to slashdot any more.

but for god's sake.... Please stop ranting about OnSite...

12 people a large project ??? by bstrahm · 2002-03-15 10:19 · Score: 5, Insightful

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 ??? by Anonymous Coward · 2002-03-15 10:53 · Score: 0, Insightful

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 ??? by Anonymous Coward · 2002-03-15 11:14 · Score: 1, Interesting

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.
Re:12 people a large project ??? by Arandir · 2002-03-15 11:44 · Score: 3, Interesting

Where I work we DON'T have this problem. Some minor glitches occur of course, but that's life. But we don't get crunchtime panic.

So what do we do that's different? I don't know 'cuz I haven't worked for some these chaotic outfits that everyone talks about. Here's some stuff that we do that might help however: the code base is divided into domains, then subdivided into feature sets; if the code in question isn't in your area, you generally don't work on it; only the feature lead checks in code related to a feature; bugs are assigned to individuals according to their area of expertise; if our code affects other areas or other domains, we alert people in those areas that we will be checking in, giving them enough time to freeze their view. Finally, and this may be a shock to some people, we actually have postponed handoff dates if we aren't ready to handoff.

--
A Government Is a Body of People, Usually Notably Ungoverned
Re:12 people a large project ??? by bstrahm · 2002-03-15 12:08 · Score: 2

Unfortunately it is not always clean... I always make the arguement when people tell me to not use a process because of deadlines that maybe we should get rid of the process when we have plenty of time since it obviously isn't optimal. I have watched too many projects fall into chaos at the end not to have this attitude...

As for projects I have shipped several 100 staff year projects in my time, both as a peon, through a team lead... If you aren't always working the most efficiently - you will never ship
Re:12 people a large project ??? by Anonymous Coward · 2002-03-15 12:25 · Score: 0

You have a limited knowledge of the actual enviroment that most programmers work with. 12 developers, being the resource devoted to a large project, is not uncommon. Also it is very common for the programming task to be akin to replacing the tire of a motorcycle while the motorcycle is moving. Despite what Microshit tries to imply, most GOOD programmers do not work for Software Houses. Most work for companies that are actulay producing something real, and need software to do it. This means that it must work ( not just look pretty on the outside like MSWord), must be supportable, and probably will be in use befor the proggraming team thinks it is ready.
Re:12 people a large project ??? by pondlife · 2002-03-15 12:41 · Score: 1

Hmm, I think the smallest project I've worked on had 6 developers, and the largest had 200+ (it failed) - 12 is definitely at the very low end.

Given a larger scale, you really have to apply an organizational solution - a technical one has no chance of working. Divide your developers into task-oriented teams (which you may well have done anyway), and make the team leaders personally responsible for coordinating coding tasks, including code check-ins.

Regarding planning, bstrahm is correct - if you only see problems when you try to compile and execute your app/architecture as a whole, then you've screwed up royally on general planning, specification and implementation tasks.

Although many coders would like to be shut in a room and allowed to do things at their own pace and using their own way of doing things, as long as someone else is paying your salary you've got to produce something that works in a timeframe that works and within a budget that works. If that's too restrictive for you, then it's time to look for another job...
Re:12 people a large project ??? by xtremex · 2002-03-15 13:48 · Score: 2

>Although many coders would like to be shut in a >room and allowed to do things at their own pace and >using their own way of doing things, as long as >someone else is paying your salary you've got to >produce something that works in a timeframe that >works and within a budget that works. If that's too >restrictive for you, then it's time to look for >another job...

That's why I no longer code for a living...I make better code under my terms

--
If you're not a Liberal in your 20's, then you have no heart.If you're still a Liberal in your 30's you have no brain.
Re:12 people a large project ??? by thomas.galvin · 2002-03-15 13:59 · Score: 1

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...

Not qutie...it is designed to produce the best bug free code in a reasonable ammount of time. As I have posted before, there is a stark difference between the "we have all the time in the world, follow the coding standard to the letter, desk check everything twice before you submit it, and code review is on Wednesday, so be early" code and the "Beta is due Monday, say goodbye to your family, and oh, could you get some soda on the way in, 'cuase this is going to be a long weekend" code. Ideally, you never get to the later, but reality seldom complies with one's ideals.

--
Thomas Galvin
Re:12 people a large project ??? by Anonymous Coward · 2002-03-15 20:08 · Score: 0

sounds a bit like the internet.
Re:12 people a large project ??? by Anonymous Coward · 2002-03-15 21:00 · Score: 0

as long as someone else is paying your salary you've got to produce something that works in a timeframe that works and within a budget that works. If that's too restrictive for you, then it's time to look for another job...

By way of bad analogy, if your boss demands that you run a 4 minute mile either get to it or look for a different job. The point is, don't assume management is clueful, don't assume programmers who want to do the job right are slackers in disguise.
Re:12 people a large project ??? by kevquinn · 2002-03-17 09:33 · Score: 1
I agree - forget arguing about tools; changing CM tools will not solve the problem, since the problem is not with the tool. The problem lies in lack of analysis and design.
If you don't control your interfaces properly you're sunk. Unstable interfaces mean:
1. You don't know what your code should do. If you did, the interface would have been pretty much correct at the start.
2. Other people in the team don't know what your code should do - how can they when you don't know - so how can they use it?
3. If anyone does use your code, they are going to have to change their code every time you change yours.
4. If no-one knows what your code should do from one minute to the next, how can it be tested?
So interfaces are key. If you want to control interfaces efficiently, you need to minimise change to those interfaces. To minimise change in the interfaces you need to know and understand what it is that your software should do. Good design and, especially, good architecture attempt to address exactly that problem.
One last point; the function of a CM tool is to provide a quality record; essentially so that one can always re-create a previous build etc. That's what they're designed for. They are not there to patch up sloppy development practices.

CVS by StarFire_FIN · 2002-03-15 10:19 · Score: 1

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).

BitKeeper by EricKrout.com · 2002-03-15 10:21 · Score: 2, Interesting

http://bitkeeper.com/Products.BitKeeper.html

If it's good enough for Linus & friends, it's good enough for me ;-)

MONOLINUX.com :: All Linux. No ads.

Re:BitKeeper by Anonymous Coward · 2002-03-15 12:57 · Score: 0

The funny thing is: this article on the site you mention flames bitkeeper to hell.
Re:BitKeeper by Anonymous Coward · 2002-03-15 14:21 · Score: 0

Hehe. Yeah, that was a few weeks ago and I found it an interesting flame fest on the Linux kernel mailing list. So, I posted it. Keep in mind that I never stated my own personal feelings on it, however many members of my site dislike BK.

Are you a member of monolinux?
Re:BitKeeper by akc · 2002-03-15 19:45 · Score: 2, Interesting

The funny thing is: this article [monolinux.com] on the site you mention flames bitkeeper to hell.
I can't see how the article flames bitkeeper to hell. It selectively provides part of the linux kernel mailing list, with the original petition against the use of bitkeeper, followed by a number of the regular kernel hackers stating that a) bitkeeper is good, b) nobody is forced to use it and c) the orginal author is listing to comments about improving it.
That definately doesn't seem like flames to me

Better Solution: Use CVS or ClearCase Properly! by noahbagels · 2002-03-15 10:21 · Score: 5, Informative

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.

Conclusion:
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! by Lumpish+Scholar · 2002-03-15 10:49 · Score: 1, Redundant

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 to "break the build."

--
Stupid job ads, weird spam, occasional insight at
Re:Better Solution: Use CVS or ClearCase Properly! by Rogerborg · 2002-03-15 10:51 · Score: 3, Interesting
- 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!
--
If you were blocking sigs, you wouldn't have to read this.
Re:Better Solution: Use CVS or ClearCase Properly! by PD · 2002-03-15 10:53 · Score: 5, Informative

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.

--
If tits were wings it'd be flying around.
Re:Better Solution: Use CVS or ClearCase Properly! by Anonymous Coward · 2002-03-15 10:59 · Score: 0

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! by _Marvin_ · 2002-03-15 10:59 · Score: 0, Flamebait

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
wrong.
In fact, I believe the original post is just a
highly successful troll!

--
"We won't use guns, we won't use bombs, we'll use the one thing we've got more of and that's our minds" - Pulp
Re:Better Solution: Use CVS or ClearCase Properly! by sn0wcrsh · 2002-03-15 11:04 · Score: 1

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! by mrm677 · 2002-03-15 11:18 · Score: 1

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!
Re:Better Solution: Use CVS or ClearCase Properly! by Anonymous Coward · 2002-03-15 11:29 · Score: 0

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! by Anonymous Coward · 2002-03-15 11:48 · Score: 0

...I find out that people never or rarely use the cvs update command to synchronize.
That's #1 on my list of 'stupid developer tricks' too.
#2 is the developer who fixes a critical bug on the current release branch, but often misses patching into either the release candidate branch or the main branch, such that the fix falls out of the next build. In an ideal world, the discovery of a critical bug would also result in changes to the QA test plan, so that this would be caught in testing, but somehow that doesn't seem to happen either.
Of course, it's easy to blame the developer, but the really the tool should take a portion of the blame. There ought to be a standard way that developers can get themselves nagged by cvs for not doing updates, and a project administrator can get a summary list of last updates for the development group. And there ought to be a way of "ordering" the branches such that when a diff is applied to a "lower" branch, the developer is asked if it should be applied to the higher branches as well.
Re:Better Solution: Use CVS or ClearCase Properly! by vil · 2002-03-15 12:30 · Score: 1

And yet I agree with you: CVS is even easier than Clearcase, and does everything you'd need to do on a typical project!

No it doesn't! If you'd said "almost" I'd agree with you, but see some of the discussion on this earlier slashdot thread.
Re:Better Solution: Use CVS or ClearCase Properly! by WolfWithoutAClause · 2002-03-15 12:34 · Score: 2

Yeah, I've been doing what most people consider a LARGE development for several years. (i.e. more than 500 software engineers working on several million lines of code... multiple continents); we're currently using Clearcase. Compared to any other tool I've used, Clearcase has a few minor issues, but on the whole it's pretty *damn* excellent, for nearly anything you could want from a source control system.

The few problems we've had are its multisite support is a shade awkward, and if you can't fit all the source into one database the 'intervob' stuff is a bit weird, and it doesn't group changes to multiple files very well. Other than that it's really, really, really excellent.

Still, CVS or even RCS is good too in my experience; but not nearly as polished.

--
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"
Re:Better Solution: Use CVS or ClearCase Properly! by thomas.galvin · 2002-03-15 14:16 · Score: 1

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

Nifty when it works...but don't get careless. We just saw a branch with three versions on it, and when it was merged to the baseline, it was the exact same file. I'm still not sure how that happened, but I'm leaning towards "cleacase lost its mind for a minute."

--
Thomas Galvin
Re:Better Solution: Use CVS or ClearCase Properly! by Rogerborg · 2002-03-15 22:17 · Score: 2
- - And yet I agree with you: CVS is even easier than Clearcase, and does everything you'd need to do on a typical project!
  No it doesn't! If you'd said "almost" I'd agree with you, but see some of the discussion on this earlier slashdot thread
OK, we don't have the same definition of "typical". ;-) Isn't that thread more of a praising of arch than a damning of CVS though? But either way, it's a great illustration that even if someone says "System XYZ is the best ever!" it's always worth taking with a pinch of salt, and doing your own research.
--
If you were blocking sigs, you wouldn't have to read this.
Re:Better Solution: Use CVS or ClearCase Properly! by dave-man · 2002-03-16 00:46 · Score: 1

Some organizational cultures naturally generate new bureaucracies. That could be the case with Rogerborg's counterparts. Or he could be much smarter than they are. Not sarcastic here -- serious. We have built successful products with four people that 200-person teams gave up on. I love to watch those smart guys go. Of course, they hired me by mistake.

--
Bill Gates is a communist -- he's just more equal than the rest of us.
Re:Better Solution: Use CVS or ClearCase Properly! by DrSpin · 2002-03-16 01:54 · Score: 1

Its a sad fact that the docs for CVS are of very poor quality, hard to find, and near on impossible to relate to.
Its another sad fact that much of the information on usenet/the web about CVS dates from version 0.0.1_beta, and says "CVS is at a beta stage, and can.t be trusted for mission critical work". Many people believe this is still the case, because there is no practical means to recall the comments.
I have used Clearcase and Teamware as well as CVS, and CVS is the cheapest, easiest to use, and most reliable of the three. It is also the one most widely used by morons. If you want a demonstration of CVS in action on large projects then try FreeBSD
Re:Better Solution: Use CVS or ClearCase Properly! by Hast · 2002-03-16 02:20 · Score: 1

Well IMHO tar -xzf is more reliable that Teamware. The version we used even segfaulted on SUN's own OS/hardware. Naturally it was a reocurring bug nad simple to recreate. I'm just very happy that I never had to perform a rollback with it.
Re:Better Solution: Use CVS or ClearCase Properly! by sn0wcrsh · 2002-03-20 04:47 · Score: 1

When you have a few number of developers your methods may work. When you approach 200-300, they fail miserably. Large scale design requires branching, merging, etc...

Being "stupid and slow" is not the problem.
200 people working on the same product is the
problem.

It's easy to be a rock-star when you are working with only 5 people.

Examdiff is WinBloze NT/98/ME... I haven't developed under MS environment in years.

Subversion! by Pointer80 · 2002-03-15 10:21 · Score: 3, Interesting

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

Cheers,

pointer

--
[%- PROCESS life -%]

Re:Subversion! by wuliao · 2002-03-15 16:01 · Score: 1

Subversion is too young. It also doesn't do merges yet. Go with Perforce. It's fast, stable as hell, atomic commits, nice API, clients for every platform you can think of.
Re:Subversion! by big_hairy_mama · 2002-03-15 21:20 · Score: 3, Informative

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.

When Subversion is ready, you might check it out. It keeps track of not specific versions for files, but revisions/patches for the entire tree. This way you can tell exactly the state of all the code at, say, revision 2735. No manual tagging needed. This would take up a lot of the work of your sequence numbers, without the severe administrative overhead. You could even try to assign a range of actual revisions for which a specific feature is targetted.

I'm already using Subversion for the early stages of one of my projects. It seems to be very stable currently, and of course I still make backups of the DB in case there still remain bugs that would corrupt it. I figure, I won't need to make any branches or merges in this project until well after the time that subversion can support it (due in April).
Re:Subversion! by brucet · 2002-03-16 16:48 · Score: 1

Subversion definitely looks interesting. It's under active development and is making fast progress. But I doubt the authors would recommend it yet for production use; it's still in pre-Alpha.

But one important feature that they don't intend to tackle is the ability to have distributed repositories. The idea is that if there are 40 developers working on a shared code tree, but a team of 6 people who are going to making major changes to the code. These 6 developers should be able to easily checkin their code to a local repository until it is ready to atomically merged into the main repository.

There's a good description of this on the BitKeeper web page.

It looks like arch is intending something similar, but the project seems to be progressing fairly slowly.

-Bruce

Modular Isolation by pyrrho · 2002-03-15 10:21 · Score: 5, Insightful

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.

--

-pyrrho

Re:Modular Isolation by Old+Wolf · 2002-03-15 10:26 · Score: 2

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 by renehollan · 2002-03-15 10:35 · Score: 2

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).

--
You could've hired me.
Re:Modular Isolation by /dev/trash · 2002-03-15 10:51 · Score: 1

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 by edhall · 2002-03-15 11:04 · Score: 2

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.

-Ed
Re:Modular Isolation by jackb_guppy · 2002-03-15 11:15 · Score: 1

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.
Re:Modular Isolation by jerdenn · 2002-03-15 13:36 · Score: 2

Ok, how do you get historical revision history, how do you find who made what change when, and can you rebuild any version of the system at any given point in time?

What about more complex ideas, like change sets? How do you associate a group of changes with a specific bug fix or change request?

These are just a few of the things a good revision control system can help provide. Without this visibility and traceability you are developing in the dark. RCS was invented for a reason.

-Jerdenn
Re:Modular Isolation by antijava · 2002-03-15 14:34 · Score: 1

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

You guys must have a pretty magical compiler that can build without even having a copy of the source.
Re:Modular Isolation by cpeterso · 2002-03-15 15:28 · Score: 1
two people shouldn't HAVE to edit the same modules.

If you take this to its logical extreme, your project will start to look somthing like this:
- Joe.cpp
- Sally.cpp
- Bill.cpp
- Kevin.cpp
- Mary.cpp
--
cpeterso
Re:Modular Isolation by Anonymous Coward · 2002-03-15 19:42 · Score: 0

No, you would have files like widget.cpp, parser.cpp, xls_export.cpp, ..., where each would start with something like "// Changes go through Sally, or you die!"
Re:Modular Isolation by big_hairy_mama · 2002-03-15 21:25 · Score: 2

That's not a problem with designing the code modularly, that's a problem (and a major one) with the company. Besides, with CVS and other similar systems, it isn't even really possible to take out a lock on a file. If your company was too stupid or too lazy to make branches and tags of the code and to learn how to do merges, then any other problems are completely secondary. You will find they all but go away when you learn how to manage the code properly and communicate between departments.
Re:Modular Isolation by big_hairy_mama · 2002-03-15 21:33 · Score: 2

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.

Rock on, dude! Prima donnas (sp?) may suck, but no matter what, 90% of the real coding is done by 10% of the coders. If I were a manager, I would rather "balance" the load by assigning each one or two developers to a specific piece of the system, and have them become experts at it. Then, I'd give all 12 fixes to the UI expert(s), and if he couldn't handle it, let him ask one of the less-busy experts in another area to help out on the changes for which the learning curve isn't too high.

Almost all software projects or mostly-self-contained components start out with one or maybe two people doing all of the initial coding. It takes a lot of work to get it to a point where more people can even start to work on it concurrently.

So if you are starting a project, plan modularly so there are not conflicts between the different "experts". Separate concerns. Also, lessons learned here will help when your project becomes so large or old that no single person knows the entire system.
Re:Modular Isolation by big_hairy_mama · 2002-03-15 21:50 · Score: 2

What I wish for is a tool that constantly downloads changes from all of the other developers' trees and highlights the lines that have changed in whatever file you're working on (but does not merge them), and optionally lets you view the changes. So you can immediately see if someone else has modified code that you want to mess with, and you can call up that person and negotiate a compromise or proper fix. Network bandwidth would be a total hog, but the time saved when you don't have to suddenly discover that someone else broke all of your changes.

Anyone up for the task?
Re:Modular Isolation by stripes · 2002-03-16 02:49 · Score: 2

What I wish for is a tool that constantly downloads changes from all of the other developers' trees and highlights the lines that have changed in whatever file you're working on

Write a small wrapper for 'cvs annotate' that colors lines with a version number newer then the current, have it display the areas around changes for a few seconds then go to the next one. Run it in another window. If your editor has hooks that can be used to tell the wrapper what files to show...otherwise keep cycling.
You could do it in under a day, at least if you only care about difference relitatave to the head of the tree. Hmmmm, wonder if I have some free time...maybe if I read slashdot less...
Network bandwidth would be a total hog, but the time saved when you don't have to suddenly discover that someone else broke all of your changes

Network bandwidth would be ok on 10Mbit ethernet, maybe even a T1 for modest size projects (and you should be able to limit this to "a few files" or a directory). Maybe there is an easy way to check what the head revision is so you can skip the costly annotate if the thing has not changed. It will suck a lot for the cvs server though.
Re:Modular Isolation by /dev/trash · 2002-03-16 08:07 · Score: 1

That's not a problem with designing the code modularly, that's a problem (and a major one) with the company. Besides, with CVS and other similar systems, it isn't even really possible to take out a lock on a file. If your company was too stupid or too lazy to make branches and tags of the code and to learn how to do merges, then any other problems are completely secondary. You will find they all but go away when you learn how to manage the code properly and communicate between departments.
Preaching to the choir there dude....

merge? by bob_clippy · 2002-03-15 10:24 · Score: 1

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).

--

-- Nobody should take away Microsoft's freedom to innovate, particularly since they haven't used it yet

Use Continuous Integration by rimsky · 2002-03-15 10:25 · Score: 3, Informative

One solution to avoid patching problem is to use continuous integration. 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. It's one of the principles of Extreme Programming, and seems to work quite well at our company.

Re:Use Continuous Integration by richieb · 2002-03-15 10:55 · Score: 2

Agreed 100%!
We develop in Java and use CruiseControl 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.

--
...richie - It is a good day to code.
Re:Use Continuous Integration by Nyarly · 2002-03-15 11:51 · Score: 1

Quick note: check out Apache Gump, which is basically the same deal. And free even.

--
IP is just rude.
Is there any torture so subl

Trying to schedule changes by kingdon · 2002-03-15 10:28 · Score: 2

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 by SerialHistorian · 2002-03-15 10:28 · Score: 2, Informative

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.

--

--
Vote for your hopes, not for your fears - Vote Third Party

Extreme Programming by Frank+Sullivan · 2002-03-15 10:28 · Score: 5, Interesting

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.

--
Hand me that airplane glue and I'll tell you another story.

Re:Extreme Programming by Lumpish+Scholar · 2002-03-15 10:40 · Score: 2

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.)

--
Stupid job ads, weird spam, occasional insight at
Re:Extreme Programming by slickwillie · 2002-03-15 10:46 · Score: 3, Funny

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 by Ctrl-Z · 2002-03-15 11:00 · Score: 1

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

--
www.timcoleman.com is a total waste of your time. Never go there.
Re:Extreme Programming by pmz · 2002-03-15 11:34 · Score: 2

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)

--
Healthcare article at Kuro5hin
Re:Extreme Programming by lkaos · 2002-03-15 13:02 · Score: 1

Ya, right. Such things don't really exist :)

The worst thing that can ever happen is to finish a project early and under budget. I worked on a small four man team that finished early and under budget (and it actually worked). Worst thing we could have done! Team blows up to a 12+ (all entry level), best guy gets moved off, more is expected, and expected in the same amount of time, and with a smaller budget then normal since we did so well the first time.

If your project isn't having a crunch time, then it's only a matter of time before it has one. In reality, management's job is to push programmers as far as humanly possible. If they aren't failing, then they aren't being pushed hard enough, and the company is losing money. At least, this appears to be managements mentality, as sad as that may seem...

--
int func(int a);
func((b += 3, b));
Re:Extreme Programming by bolthole · 2002-03-15 13:32 · Score: 1

If you ever finish a project without crunch time, the marketing guys will find out and have your schedules shortened appropriately.
This also fits in the original premise of "you[r company] arent doing programmer management correctly.
A good manager will get a ludicrous schedule from marketing, and tell them in business language, "screw you, it cant be done in that amount of time". If the manager ever lets something like that slide, then he will get more outrageous demands the next time.
One of the functions of a good manager, is to protect his underlings from stupidity from higher up.
Re:Extreme Programming by stripes · 2002-03-16 04:16 · Score: 2

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

Not a chance. Marketing doesn't pay anything for having programmers being stressed. They don't pay much for having a product being buggy (unless it is buggy enough to kill the company). They do gain something from having a new product with new features to bullet point (they also gain something from being able to specify features that will later be bullet points in ads, on boxes, or on slides).
So marketing will push hard for unrealistic schedules. Crunch time or not. The only way to avoid it is to have management (or in a small company you) pushing back hard enough to keep the schedule sane. Even if you are insanely good ("two new server products in 4 weeks? No problem") that normally buys you more insane schedules in the future (and one would hope a bonus, raise, or some now worthless stock). Of corse if you are really good, that can be fun for a while, but some day you will miss your family, other hobbies, and seeing the day star.
Re:Extreme Programming by alext · 2002-03-16 14:31 · Score: 2

Some XP contributors did a 'manifesto' or something recently and used the terms 'agile programming', 'agile methods' etc. which I certainly prefer

Why are patches applied multiply? by Anonymous Coward · 2002-03-15 10:29 · Score: 5, Insightful

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.

--tsw

Re:Why are patches applied multiply? by smurfi · 2002-03-16 21:33 · Score: 1

CVS forces you to apply patches (or merge branches, which is essentially the same thing) multiple times.
it happens like this:
- You fork off a branch and edit file X, which is also touched in the mainline.
- You merge the mainline into your branch, e.g. because you need a bugfix from it. CVS forces you to resolve the conflict, which is Good.
- Two weeks later, you merge again. Again, CVS says that there is a conflict in file X -- which you already resolved!
The reason for this is that CVS lets you merge branches, but it doesn't remember that you did so -- you have to do that in the CVS comment.
Personally, I use BitKeeper. It may not be 100% free code, but at least it works.
You can work around all the CVS problems given enough discipline and code structure, but the point is that there's a tool which lets you structure your code the way you need and not the way it needs -- so why bother?

Source Control + Automated Build & Test by spullara · 2002-03-15 10:32 · Score: 4, Informative

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. 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 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.

Good luck,
Sam

--
"If I can see farther it is because I am surrounded by dwarves." -- Murray Gell-Mann

Re:Source Control + Automated Build & Test by Tet · 2002-03-15 10:50 · Score: 3, Insightful

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).

--
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Re:Source Control + Automated Build & Test by vinn01 · 2002-03-15 11:39 · Score: 1

> 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.
Re:Source Control + Automated Build & Test by spullara · 2002-03-15 13:15 · Score: 1

I said that you might try Bugzilla, not that it would be any good. None of the bug tracking systems that I have used have been any good except for ones built to your development groups specifications.

--
"If I can see farther it is because I am surrounded by dwarves." -- Murray Gell-Mann
Re:Source Control + Automated Build & Test by Electrum · 2002-03-15 14:28 · Score: 2

I recommend checking out Mantis if you need a good, simple, easy to use and configure bug tracker. You can have it installed and working in minutes, and only requires PHP and MySQL. The source is very clean, so it's easy to make changes to it. And the developers are very good about accepting bug reports and feature requests. For a large project like Mozilla, you might need something more large scale, but for small or medium size projects with 10-20 people, it works very well.
Re:Source Control + Automated Build & Test by cpeterso · 2002-03-15 15:33 · Score: 1

yes, Perforce rocks. I've also used Microsoft Visual SourceSafe, which is worse than NO version control! It has weak support for branching, no atomic checkins of multiple files in one changelist (like Perforce), 4 GB database limit, and your database gets corrupted weekly..

--
cpeterso

nerdz by Anonymous Coward · 2002-03-15 10:33 · Score: 0

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 . by mryken · 2002-03-15 10:34 · Score: 1

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 by Anonymous Coward · 2002-03-15 10:36 · Score: 0

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 by kippy · 2002-03-15 10:36 · Score: 1

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.

--
Blaze a trail to the New World

Re:CC by renehollan · 2002-03-15 10:43 · Score: 2

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.

--
You could've hired me.

Patch/Tree Manager and/or per-developer branches. by jordan · 2002-03-15 10:38 · Score: 2, Interesting

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.

--jordan

This sounds like an architecture problem by McMuffin+Man · 2002-03-15 10:38 · Score: 3, Insightful

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 by gbr · 2002-03-15 10:39 · Score: 1

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 by Anonymous Coward · 2002-03-15 10:40 · Score: 1, Insightful

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?

Re:Sounds like no one is in charge by Anonymous Coward · 2002-03-15 11:57 · Score: 0

our development policy is that whoever breaks the mainline buys beer. wonderful motivator. unfortunately, we're using VSS in our current project, after i've used (and evangelized) clearcase and CVS extensively. VSS sucks, straight up.. its like a time bomb waiting to go off. nothing has quite given me the confidence in a version control/configuration mgmt. tool as ClearCase. I've had junior developers trying to learn clearcase come to me and be like "i think all my source is gone". of course it isn't, silly. clearcase never forgets!

Product Management and Strong Architecture by dant · 2002-03-15 10:41 · Score: 5, Interesting

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 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 by ZeroConcept · 2002-03-15 10:41 · Score: 2, Insightful

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 by ethereal · 2002-03-15 10:46 · Score: 1

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.

--

Your right to not believe: Americans United for Separation of Church and

Sequence number solution fatally flawed by Frank+Sullivan · 2002-03-15 10:48 · Score: 2

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.

--
Hand me that airplane glue and I'll tell you another story.

Methodologies and Tools by soap.xml · 2002-03-15 10:49 · Score: 2, Informative

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 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 ;)

-ryan

Re:Methodologies and Tools by Anonymous Coward · 2002-03-15 20:26 · Score: 0

there is this cool language called "whenever", it works well with "cvs" and it helps with scedualling

black box by beauzo · 2002-03-15 10:49 · Score: 1

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 by josepha48 · 2002-03-15 10:49 · Score: 2

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.

--

Only 'flamers' flame!

What you are doing isn't concurrent development! by Kaz+Kylheku · 2002-03-15 10:51 · Score: 4, Insightful

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 by VictimlessChris · 2002-03-15 10:52 · Score: 2, Interesting

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.

--
Then I put on a suit, because you can get away with anything if you're wearing a suit. Suits lie.

Re:Clearcase branches by conradp · 2002-03-15 12:01 · Score: 2, Interesting

As someone who has used both CVS and ClearCase extensively, I'd say that this points out one of the major problems with ClearCase: checked-in files are seen immediately by all developers. (This is sometimes touted as an advantage, or even a "feature".)

CVS lets developers update to see other people's changes at their own convenience. But that also means developers need to exercise some discipline to update frequently enough that their code does not remain too far out of sync with the baseline. This, combined with a "checkin early and checkin often" approach, should really minimize the number of conflicts, even for fairly large projects.

I can't imagine the problems that the original poster described ever happening with proper use of CVS, but perhaps there's something in that "developing patch sets" phrase that he hasn't fully explained to us.

Just a couple of other thoughts:

Distributed ClearCase works reasonably (though I wouldn't say well) for projects that have a few interconnected sites, but is not well-suited at all for a project involving many different developers each in a different location. CVS is ideally suited for that type of environment.

CVS really needs a way to move or rename files, and a way to do atomic checkins of multiple files. When will this happen? I know, "sooner, if I help."

No version control system should prevent people from fixing code just because the code "belongs" to someone else, or is "being modified" by someone else. This sort of "coordination" and "planning" obstructs progress more than hinders it.

Although it's possible in theory for an automatic merge to succeed while being semantically incorrect (with either CVS or ClearCase), I've never once seen it happen. If your code is well-written, the dependencies on certain assumptions should be fairly collocated, not spread all over the code where they could get out of sync.

In a large, well-segmented project where the "frequent checkin" policy is used, it is rare indeed that two people even modify the same file at the same time, let alone modify the same lines.

--
"To be absolutely certain about something, one must know everything or nothing about it." -- Olin Miller
Re:Clearcase branches by thomas.galvin · 2002-03-15 14:47 · Score: 1

CVS lets developers update to see other people's changes at their own convenience.

So does clear case, though it might not be intuitive...look in the docs for adding time rules to your config spec. This lets you look at "all files baselined on or before March 3rd, 2002," or someting simmilar.

--
Thomas Galvin
Re:Clearcase branches by Anonymous Coward · 2002-03-15 17:41 · Score: 0

"checked-in files are seen immediately by all developers"

No...

Clearcase has a far more structured approach to preventing exactly this in the form of private branches (which is known in trendy circles as activity based SCM). You work on an activity until you are ready to publish it. You can check in and out to your heart's content and it doesn't affect other developers.

Contrast this to CVS, where you work on your local filesystem for large amounts of time without the ability to checkin for fear of affecting other devlopers.

With activity based SCM, I can check in as soon as I'm sure code compiles, or part way through my task when I reach a particular stage. And I can see the version history within and without my task.

CVS is really easy to use ( I use it a lot for open source stuff ), but I'd never give up activity based SCM for professional development where we work with hundreds of developers across three countries. I just really wish someone would build dynamic views and activities into CVS so I could use it for free at home :)

I can't understand why you think CVS is better at distributed SCM than Clearcase. How can you justify this? CVS doesn't even have any replication features at all. Period. At my company, we use Clearcase in three countries around the world and replication works just fine.

CVS doesn't even version directories, for goodness sake.

About merging: I perform automatic merges several times a week with Clearcase, it very, very rarely gets it wrong. CVS on the other hand is a nightmare when it comes to merging.

My company is one of Rational's biggest competitors, so I wouldn't normally be so supportive of them, but they really did write a kick-ass SCM system in clearcase.
Re:Clearcase branches by conradp · 2002-03-15 19:42 · Score: 1

"checked-in files are seen immediately by all developers"

No...

Well, it sounds like ClearCase has improved since we gave up on it several years ago, but at that time the only way to prevent this seemed to be establishing a private branch. The way we were using it, branches couldn't be set up by developers, only by administrators, and merging branches was an endeavor that was only performed by the designated "merge and build manager" after much coordination. (Though clearmerge was a very handy tool for 3-way merging!) Evidently despite numerous training classes, the ClearCase administrators still didn't get how to use the thing effictively.

I can't understand why you think CVS is better at distributed SCM than Clearcase. How can you justify this? CVS doesn't even have any replication features at all. Period. At my company, we use Clearcase in three countries around the world and replication works just fine.

With ClearCase your working directory is a virtual directory hosted by the ClearCase server. If that server goes down or you lose connectivity to it, you're dead and can do nothing. Period. So in that framework distributed SCM requires replicating the repository and syncing up repositories periodically. (We used to do it automatically every night.) If you wanted to see someone's changes from a remote location immediately, too bad - unless you wanted to log in, generate a repository sync package, ftp it over, and apply their changes to your local repository manually, that is. (Or rather, ask the ClearCase administrator to do it...) I believe you had to temporarily shut down the server to apply synchronization packets to the repository, so synch'ing during the work day was out of the question.

With CVS you can write your code on a laptop on the beach, then connect your cell-phone modem to connect only when you want to checkin or update. So you don't need to replicate the repository to achieve distributed SCM.

My company is one of Rational's biggest competitors, so I wouldn't normally be so supportive of them, but they really did write a kick-ass SCM system in clearcase.

Then I'm sure you know they didn't write it - they bought it!

--
"To be absolutely certain about something, one must know everything or nothing about it." -- Olin Miller
Re:Clearcase branches by ebh · 2002-03-16 17:54 · Score: 2

one of the major problems with ClearCase: checked-in files are seen immediately by all developers.
Not if you're using UCM. In fact, in UCM it's hard to make changes immediately visible. (The problem I have is that most of the l^Husers in my shop come from the throw-it-all-in-a-pile school of SCM, and insist that ten minutes is too long to wait to see another developer's changes.)

Division of ownership/responsibility by PureFiction · 2002-03-15 10:52 · Score: 4, Insightful

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:
RootBranch | |-- 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)

Re:Division of ownership/responsibility by Anonymous Coward · 2002-03-15 21:51 · Score: 0

Why can't you spell?

On CVS and Clearcase by ajs · 2002-03-15 10:53 · Score: 5, Informative

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.

Re:On CVS and Clearcase by curunir · 2002-03-15 12:38 · Score: 3, Interesting

CVS is most everything you want from revision control

What about file locking, code promotion, build labels or grouped check-ins? As far as I know, CVS has none of these. These are big issues.

File locking removes the need for constant branching. Granted CVS's automatic merging capabilities are more advanced than most of its competitors, but branching is the enemy. It should be avoided unless it is absolutely necessary. You lose the ability to have two people work on the same file at once but, from my experience, saving yourself the hassle of losing changes is a big plus.

Code promotion (as I understand it, I haven't worked too extensively with it) is nice because it allows developers to continue development while their code moves through the QA process and have their bug fixes easily merged back into the source tree.

Build labels are great because it allows you to group file versions into a logical release (rather than just the current version at a specific date).

Grouped check-ins are probably the feature that is most lacking in CVS. It amazes me how many people won't call MySQL a real database because of its lack of atomic transactions but are still willing to call CVS a version control system. If all application code was contained in one file, this wouldn't be necessary. However, it is often necessary to make a change to one file that requires a change to another file. If these files are checked in individually (as CVS does it), it is possible to get version conflicts with these files. To make matters worse, if the change needs to be rolled back, you have to remember to roll back both files. The situation gets exponentially worse the more mutually-dependant files you check in.

The only real advantages of CVS over most commercial versioning software are
a) free...important for open source projects without funding.
b) readily available to make your source tree available to people outside your development team...also important for open source projects.
and c) the large selection of front ends (gui,text, web and otherwise) that have been written for it.

However none of these features qualify it as being an "advanced" (as the original post called it) version control solution.

--
"Don't blame me, I voted for Kodos!"
Re:On CVS and Clearcase by scottmartinnet · 2002-03-15 13:46 · Score: 1

File locking: The CVS philosophy says you shouldn't use it, so it's a bit obfuscated, but it's still there, in contrib/rcslock.

Code promotion: I don't understand it from your description.

I think "build label"=="release tag", but I'm not entirely sure from your description.

Grouped check-ins: I have *never* had a problem with this, as long as I execute a clean update right before I commit. The CVS database is locked when someone else is checking in, so unless someone is able to get an entire commit done in those seconds between the end of your update and the beginning of your commit, you're fine. If your development team is big enough to make this a real problem, you have bigger things to worry about.

CVS has done everything we need it to, and has saved my butt more than once.
Re:On CVS and Clearcase by douglips · 2002-03-15 13:55 · Score: 1

File locking removes the need for constant branching. Granted CVS's automatic merging capabilities are more advanced than most of its competitors, but branching is the enemy. It should be avoided unless it is absolutely necessary.

I don't understand your reasoning here. Why do you have to constantly branch if you can't lock files? Why can't you (as I do) just merge in other people's changes before you check your changes in? 95% of the time there are no conflicts and it is no extra effort. If there is a conflict, then merging it by hand is necessary - the alternative is that you could not have worked on the file at all until Joe Slow checks his stuff in. Bogus.

Furthermore, branching can be very useful and if you set up some automated merge procedures it is pretty painless (see "Code Promotion" below.)

Code promotion (as I understand it, I haven't worked too extensively with it) is nice because it allows developers to continue development while their code moves through the QA process and have their bug fixes easily merged back into the source tree.

I'm not familiar with the term "code promotion". It sounds like you simply want to be able to have a release version debugged while you continue development on the next version.

In CVS, this is pretty simple to do using a branch. Just create a "release candidate" branch. As bugs are fixed, you merge the deltas on the branch into the main development version. So, as QA finds bugs, you fix them on the "release candidate" branch, and every night or every week or whatever they get merged in to the development "trunk".

Build labels are great because it allows you to group file versions into a logical release (rather than just the current version at a specific date).
? This is a feature of CVS dating back as long as I've been using it. You 'tag' the files in the release. Later, you can ask for those versions just by doing cvs checkout -r tag. If the need arises, you can branch off of that tag, and then use the branch name to get the latest version of the branch. You can then tag the branch, branch from the branch's tag, ad nauseum. It's freaking fantastic.

Around here, we do a build every night, and tag each of these builds. As we near release, this means we have a release candidate build done every day, and we can guarantee that we can recreate the source files for that build.

Grouped check-ins are probably the feature that is most lacking in CVS.

Unless I misunderstand you, this is also a feature of CVS. If I change 20 files and go to check them in, any problem in the check-in process results in none of my changes being checked in. It is atomic as far as I can tell.

Usually the problems that occur that prevent checkin simply require me to update and merge in (again, 95% effort free) other peoples changes. Then I try to check in again and it works.

--
My amazing wife - Artist, Author, Philosopher - Laurie M
Re:On CVS and Clearcase by Anonymous Coward · 2002-03-16 06:54 · Score: 0

As pointed by others, you don't know shit about cvs.

Furthermore, beeing 'free' don't mean that it is made for money-starved open-source developers. It means that no-one will get your code in hostage.

Free. Like in Freedom.

Cheers,

--fred

Not generally a problem with Open Source... by sultanoslack · 2002-03-15 10:54 · Score: 1

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 by markj02 · 2002-03-15 10:55 · Score: 2

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! by feloneous+cat · 2002-03-15 10:56 · Score: 2, Interesting

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...

--
IANAL, but I've seen actors play them on TV

Just use CVS ... by Anonymous Coward · 2002-03-15 10:58 · Score: 0

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 ...

Re:All your FP by Rad+Didio · 2002-03-15 10:58 · Score: 0

(I prefer white paste) US...

Why not make the coding realtime? by HanzoSan · 2002-03-15 10:58 · Score: 2

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

An IDE interface which is sorta like IRC or something

--
If you use Linux, please help development of Autopac

Re:Why not make the coding realtime? by Mulletroll · 2002-03-15 11:19 · Score: 1

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.
Re:Why not make the coding realtime? by HanzoSan · 2002-03-15 14:28 · Score: 2

I've thought about it in detail and even have ways to do it.

Start a project and I'll help but i cant really code well enough to help in that area, maybe in design and documentation and other little areas.

--
If you use Linux, please help development of Autopac

Maybe the software is not the problem by Ctrl-Z · 2002-03-15 10:58 · Score: 1

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.

--
www.timcoleman.com is a total waste of your time. Never go there.

Re:Maybe the software is not the problem by Anonymous Coward · 2002-03-15 20:35 · Score: 0

Very strange. I know at /. is always politically corerct to say a Microsoft product is the crappiest thing in history, but at my company we use Visual Source Safe 6 since it's release (never tried VSS 5 tho), and it's a pure charm. We *never* encountered any problem since, and we use it as non-exclusive checkin. Sometimes it may have like 4 or 5 programmers working in the same file at the same time, and everything is always merged perfectly. Once in a while VSS don't know how to resolve some merging, then it let the programmer easily resolve the ambiguity.

As for my personnal experience, VSS is the best and easiest versioning soft I ever used.

What we did by raju99 · 2002-03-15 11:13 · Score: 1

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.

Re:What we did by Anonymous Coward · 2002-03-15 12:53 · Score: 0

And (best of all) by having the bulk of the slave labor accessing it from another country via the web client you can prevent your offices from smelling like curry for when the clients visit!

Cheap Marketing Ploy by VA Software? by ONU+CS+Geek · 2002-03-15 11:13 · Score: 3, Funny

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.

--

I disable sigs...do you?

Perforce! by Boone^ · 2002-03-15 11:14 · Score: 2

At work we use Perforce 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 by spludge · 2002-03-15 11:15 · Score: 1

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

Re:Locking files by Anonymous Coward · 2002-03-15 14:26 · Score: 0

Currently I am forced to work with VSS. After using CVS and Envi (spelling?) for the past 2 years, I find it a total step backwards.

Working on a C# project with 3 other developers using VSS is a royal pain. We are currently going through a developement section where we are adding a lot of classes. Every time you add a class you have to check out the project file for Visual Studio. God forbid anyone would want to create a class at the same time.

Also things like renaming a file is a real pain with VSS and Visual Studio.

You mentioned that there are always other things to do. You are correct. But just because there are other things to do, doesn't mean you should do them.

There is always a price involved with a task switch. Good programmers get into a groove and can really crank out a lot of high quality code in a short time. But interrupting them can be costly.

Why should you have to pay the price for interrupting them, when you can just get a good tool that can handle the concept of concurrent work going on. Especially if that good tool is free like CVS.

My 2 cents
Re:Locking files by sadr · 2002-03-15 16:48 · Score: 1

The short answer is that it serializes development.

Let's say that you want to add a new paramter to an existing function. You have to touch 25 different source code files that call this function.

You now have to wait until all 25 files are available to be checked out before you can make your change. If someone checks out a file, and then goes on vacation for two weeks, you're stuck.

With a parallel development system, and decent merging software, you just change the files, and when the guy gets back from vacation, he has to merge his changes into the current baseline.

With even medium numbers of developers (N > 25), parallel development is essential to efficiency. Without parallel development, you end up with a potentially large fraction of your developers waiting on something to get finished so they can make their change.
Re:Locking files by Anonymous Coward · 2002-03-15 20:37 · Score: 0

You are using sourcesafe? Source is nothing but a history tool disguised as a CM tool.

People have to trust the system by eison · 2002-03-15 11:17 · Score: 2, Insightful

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.

--
is competition good, or is duplication of effort bad?

Perforce and process recommendation by enkidu · 2002-03-15 11:19 · Score: 3, Informative

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 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 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 up on their site, as does Perforce.

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.

--

There is no trap so deadly as the trap you set for yourself
-Raymond Chandler, The Long Goodbye

Re:Perforce and process recommendation by BigRedZX · 2002-03-15 14:10 · Score: 1

What a day to not have mod points.

Perforce is *the* SCM tool.

One more thing: atomic operations. by enkidu · 2002-03-15 11:30 · Score: 2

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.

--

There is no trap so deadly as the trap you set for yourself
-Raymond Chandler, The Long Goodbye

Re:One more thing: atomic operations. by curunir · 2002-03-15 13:00 · Score: 2

Exactly...this is an *important* feature. It makes backing out changes soooooooo much easier.

--
"Don't blame me, I voted for Kodos!"
Re:One more thing: atomic operations. by Anonymous Coward · 2002-03-15 13:24 · Score: 0

Might want to look into subversion which also supports atomic operations.

It's intended as a conceptual replacement for CVS, but without all the things that people hate about CVS (i.e. cvs doesn't track metadata, renaming files is evil, etc).
Re:One more thing: atomic operations. by Eccles · 2002-03-15 16:02 · Score: 1

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.

Sure you can, Perforce doesn't actually test that the changes build, it just requires you to reconcile any differences between when you check out and when you check in. Now, if you combine Perforce with an autobuild system that tags changelists regarding whether a compile succeeds, that's kick-ass. Combine that with automated regression tests that tag whether a particular changelist passes the regression test, and you're nearing a li'l piece of heaven...

--
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Re:One more thing: atomic operations. by ebh · 2002-03-16 17:46 · Score: 2

UCM in ClearCase does exactly this. You may or may not like the policy that's hardwired into UCM, but UCM's "activities" do indeed atomicize the checkin of groups of files.
Re:One more thing: atomic operations. by enkidu · 2002-03-16 21:18 · Score: 1

Perforce's change review daemon is perfect for this. Modify it to autobuild/test each changelist, and email result to the responsible party after completion. The review daemon is written in Python so its pretty easy to read and modify. Perforce has the keys to those pearly gates it seems.

--

There is no trap so deadly as the trap you set for yourself
-Raymond Chandler, The Long Goodbye
Re:One more thing: atomic operations. by enkidu · 2002-03-16 21:36 · Score: 1

With UCM, you do get atomicized checkin's but it's still a hack on top of ClearCase. Basically, you may get atomicized checkin's but you also get a dumbed down/crippled window into the powers/features of ClearCase. Perforce has atomicized changelists as a fundamental concept to its change control model. Having worked with both, with ClearCase as the change management gate keeper and with Perforce as the perforce administrator and *NIX build meister, I prefer the Perforce change model. (I also prefer Perforce's licensing terms/customer service/technical support.)

--

There is no trap so deadly as the trap you set for yourself
-Raymond Chandler, The Long Goodbye

If this is a problem, your methodology is broken. by ProtonMotiveForce · 2002-03-15 11:30 · Score: 1

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.

HOW DOES THIS ANSWER THE QUESTION? by Anonymous Coward · 2002-03-15 11:31 · Score: 1, Funny

good lord

NICE AD

managed branching and merging by tjuricek · 2002-03-15 11:32 · Score: 2, Informative

(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.

-T

General Suggestions by MidKnight · 2002-03-15 11:34 · Score: 4, Insightful

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,

--Mid

LARGE? by MosesJones · 2002-03-15 11:38 · Score: 2

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

--
An Eye for an Eye will make the whole world blind - Gandhi

Re:LARGE? by Dasein · 2002-03-15 11:57 · Score: 1

Absolutely! Once projects get above about 3 people somebody has to be the grown-up. Linus is the grown-up for Linux. You've been the grown up for your projects. I've been the grown up for teams of 35 people shipping 4 different products - I had help, of course.

This team seems to lack a grown-up.

No tool can play grown-up for a project. My first job, everybody on the team was a grown-up except me (give me a break I was 19 and it as my first programming job). That team did it all without version control tools. Not the best way by far but it can happen.

On the other hand, my second programming job was for a bank that used PVCS. They were missing grown-ups so a lot of their projects crashed and burned.

--
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.

Re:Extreme Programming -- For fools by MosesJones · 2002-03-15 11:41 · Score: 2

Test first....

But tests are written by the developers, so good developers = good tests, bad developers = bad tests.

Don't do XP, anything in engineering that says Requirements and Design don't come before implementation lose the right to be considered engineering.

--
An Eye for an Eye will make the whole world blind - Gandhi

They are not, if I read it correctly. by Kaz+Kylheku · 2002-03-15 11:42 · Score: 2

The way I understand the text of this article is that the patches have to be reworked several times. This is integration work, not submission work. The developer makes a change which depends on some other change, but rather than waiting for that other change, just goes ahead and does it. Then when the dependent change comes in, the patch is wrong and has to be reworked. Am I close?

Continuous Integration by sohp · 2002-03-15 11:43 · Score: 2

Sounds like a more coordinated build process would help out a lot. Martin Fowler's article Continuous Integration talks about this problem,

The fundamental benefit of continuous integration is that it removes sessions where people spend time hunting bugs where one person's work has stepped on someone else's work without either person realizing what happened. These bugs are hard to find because the problem isn't in one person's area, it is in the interaction between two pieces of work. This problem is exacerbated by time. Often integration bugs can be inserted weeks or months before they first manifest themselves. As a result they take a lot of finding.

If you're not already familiar with the Mozilla Tinderbox you should examine carefully how they coordinate ten simultaneous and continuous builds across 3 different operating systems with dozens of developers scattered across timezones.

"Disappearing" fixes by Anonymous Coward · 2002-03-15 11:45 · Score: 1, Insightful

Believe me, I have experienced your pain, and we weren't even using multiple branches.

It sounds to me as though your developers are NOT updating their local ("sandbox") versions before they merge their changes back in.

Developer A: checks out file, starts work.
Dev B: checks out same file, starts working.
Dev B: finishes, commits changes to CVS.
Dev A: finishes, commits changes to CVS without updating first.

Developer B's committed changes are GONE!

Make it easy on yourself, and do NOT let multiple developers check out the same file.

Enjoy Coca-Cola! by Anonymous Coward · 2002-03-15 11:46 · Score: 1, Interesting

what's worse: having VA Software promoted on a VA property?

or having it mod'd up to 5, while competitor (bitkeeper) suggestions mod'd down?

Another thought: dependency inversion. by Kaz+Kylheku · 2002-03-15 11:52 · Score: 2

If you want to improve parallelism when people work on different pieces of the same program, try to stabilize the interfaces early. Then two or more developers can walk away and do their thing independently of the others: they are all dependent on the interfaces which change very little, and not on each other.

This is not quite the same thing as merely decomposing a program into modules. It's decomposing a program into modules which have well-defined interfaces that have an identity of their own. But there are other things that are interfaces.

An interface is convention by which two parts of an application relate to each other: a set of functions with given arguments and semantics; messages exchanged over a network; file formats or database schemas, directory structure layouts, names of files, language syntaxes, and so on. Essentially anything which has structure and which is formed in one place, and interpreted in another. All such structures create dependencies, and the dependencies must be identified and managed if you want to know how to parallelize development.

Software engineering by Tim+Ward · 2002-03-15 11:53 · Score: 2, Insightful

There's a well known answer to this (and many other problems that amateurs run across time and time again) - see subject.

Re:Extreme Programming -- For fools by Arandir · 2002-03-15 11:54 · Score: 1

Don't do XP, anything in engineering that says Requirements and Design don't come before implementation lose the right to be considered engineering.

Bingo. XP is just a spiral lifecycle stuck in maintenance mode.

--
A Government Is a Body of People, Usually Notably Ungoverned

Well designed code avoids these issues by zorander · 2002-03-15 11:54 · Score: 2, Insightful

The problems mount as the source files get longer. On the project I'm currently working on, we have an average of 80-100 lines per file. Are some files abnormally huge? Yeah, but for the most part the files are small. Some times a file has to be a little bigger than that to perform its function. Of course with only a few lines of code per file, it will be very rare that more than one developer will have to touch it at a time, and furthermore, there's only room for so many bugs in 80-100 lines before it becomes more worthwhile to rewrite it. If the code is really that buggy, then the small source files will make it easier to gradually reimplement sections and make the task seem less daunting to the developers. Also, If the interfaces are intelligently designed and well documented in advance, then you have the ability to reimplement files without causing troubles. When I open up a piece of someone else's code and find a 7000 line source file (I've seen 20000 line source files in some projects...one piece of control software had an entire user interface implemented in xlib and network communication layer in one 20,000 line file), It becomes a formidable task to understand it well enough to fix or improve it. If the source files are small and their purposes well defined, then everything gets along better.

Brian

Checkin Token by Technomancer · 2002-03-15 12:04 · Score: 2, Interesting

In one company I worked for we used Perforce and checkin token file. Only the person who had the token was allowed to check in, also he had to smoke test the project before releasing the token. We also had a tradition of adding haikus to the checkin token file. You can read them in one of easter eggs :)

Perforce is the way to go. by h4x0r-3l337 · 2002-03-15 12:13 · Score: 2, Informative

The last two companies I worked for used Perforce, and it solves this quite nicely. It will tell you if a file you want to check in has been changed by someone else in the mean time, and will help you merge in that person's changes before you make your checkin. Perforce is extremely powerful and easy. The only reason *not* to use Perforce is if you're hung up on using an open source product for your source-repository needs. If you just want to get the job done, you use Perforce. For home use, they even have a limited (2-user) version. For open-source projects, they offer free licenses as well.

Make developers mere on checkin by SuperKendall · 2002-03-15 12:23 · Score: 3, Informative

I have used both CVS, Clearcase, MKS, straight RCS, and a bit of Visual Source-Safe (Ha!).

What I have found makes the most difference in reducing merge issues is (1), have developers merge on checkin (more on that in a moment), and (2) develop a branching strategy that reduces the need to merge.

On (1). When using ClearCase, have people set checkouts to be "unreserved". When they check out a file it won't lock it so everyone else can use it, and when they check something in ClearCase will force them to perform a merge if it has been updated since they checked it out. Make everyone learn how to use the henious merge tool. Also (and I'm not sure if this is fixed now or if I never figured out how to configure this right) I have had major issues with EOL markers in files and clearcase merge - if a developer edits a file that changes the EOL character(s), then ClearCase merge will claim the whole file differs.

For CVS, it pretty much works naturally the way a system should - the default is to check out something "unreserved" (or at least that's how I remember it!). You can either update a file while you're making changes to keep up to date an make merges smaller, or just wait until you're done - before you can check it in CVS will make you update the file and merge your changes.

In both systems, an approach of having the developer merge the file means the person who really knows what's going on can resolve any conflicts with the merge. Most merges are automatically handled and so often no work is required. I'm not sure how much this really addresses your issue, but it can't hurt to rely more on the source control system helping you manage merges.

For option (2), think carefully about how you want to structure releases. One approach I've used before is having dfferent "levels" of development - you have a production branch, fix branch, development 1, dev 2, etc. You start out code at some given level (say development 2) and as it is completed and tested it moves up through the ranks until it reaches the production level. That worked pretty well and meant a fixed number of branches.

In more recent projects I've been working with a monthly release structure - each months release requires a new branch. This was not my idea, believe me... it might seem nice in theory but in practice you might have three or more months of development at the same time. This leads to something of a merging cross-nightmare. Some sort of branching structure might well help solve your problem, if only in thinking up how you can more clearly seperate changes to a file or set of files.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley

What language is SourceForge written in? by Anonymous Coward · 2002-03-15 12:27 · Score: 0

I'm especially curious as to what language VA Whatever picked to write the web-based admin in.

Transactional updates by enkidu · 2002-03-15 12:28 · Score: 1

Perforce has atomic transactions. Perforce has a slightly biased (but not much) comparison of p4 to cvs. Atomic transactions plus easy administration makes it worth the price for my company.

--

There is no trap so deadly as the trap you set for yourself
-Raymond Chandler, The Long Goodbye

-1, Blatant Plug + Troll... by Anonymous Coward · 2002-03-15 12:32 · Score: 0

Sheesh. What editor is modding up all these VA Software advertisements as "Interesting" or "Informative"? And there's a cute little Microsoft bash thrown in at the bottom too, with absolutely no evidence thrown in (or even the name of the Microsoft software that this person used!) Disgusting.

The CVS Way by SJS · 2002-03-15 12:33 · Score: 4, Insightful

[I am not a CVS guru, I just use it.]

If you have to apply patches multiple times, then you're probably patching branches, and developing in the branches. The "CVS Way" seems to be (corrections welcome) to develop in the default branch, and to tag the tree at drop-points -- when you ship the code. If you need to support an old code-drop, you turn the tag into a branch, and then patch the branch.

If you have too many delivered branches being supported at the same time, perhaps you should upgrade those customers to a newer version of the software. They'll appreciate, and it will simplify your situation.

The develop-in-a-branch-and-ship-the-default is appealing, but troublesome.

Otherwise, it sounds like your developers aren't playing nice... developer A patches the tree, and developer B goes to commit his changes, but gets told that there are conflicts and that he needs to update. Not wanting to deal with the conflicts, he copies his important files to a save spot, updates, copies his "important" files back over the top of the conflicted files, and then commits the whole thing, effectively "rolling back" the patch.

If this is what is going on, you need to educate your developers. With a stick.

Over the years, I've discovered that a significant amount of heartburn I may have with CVS comes not from any deficiency of CVS, but from the fact that I frequently fail to use CVS "properly" -- meaning, of course, "as intended".

--
Pick One: http://www-rohan.sdsu.edu/~stremler/sigs/sigs.html (Note - disable Javascript first!)

The Free Software solution! by Anonymous Coward · 2002-03-15 12:34 · Score: 2, Informative

We all know that BitKeeper isn't free software, and I don't really know why it was chosen by Linus to manage Linux development since we have a much better solution in arch.

I think it is great. It follows the *nix spirit, spliting a problem in lots of little parts as addressing each part with one pre-existing tool or some home-made bash scripts. For the diff/patch lovers (like myself), it is great to find another uses for these tools.

I used to use CVS... but it doesn't scale so good. When Linus move to BitKeeper, I give it a try... but it was so disappointing. So I decided to give arch a try.... I am using it 'til now.

You can check it here.

Re:The Free Software solution! by Anonymous Coward · 2002-03-15 13:04 · Score: 0

I tried arch, but all I got was this:

[me@duckman]$ arch
i586

Re:Extreme Programming -- For fools by Nevyn · 2002-03-15 13:05 · Score: 1

Anyone that says you can do a complete, and working, requirements and design phase _before_ you do any kind of implementation is living in some other reality.
Even when you get to the level of complete Z specifications, all you've done is implement the solution in a language that only humans currently understand. Way to go!

--
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B

Here's what we do by Anonymous Coward · 2002-03-15 13:07 · Score: 0

I am dead serious, this is how we handle it.

No revision control system. The code is just on a server that all the stations have mounted. Programmers edit what they need to. If you notice some of your work just disappeared, you shout out, "hey, who's working on foo?" Then one of you two decides to work on something else for a while.

The real trick is this: we don't have "crunch time" so we don't bump into each other. If you've got 12 programmers all working on the same code in a hurry, then you have management problems, not technical problems with concurrency. Threads inside a computer needs to deal with concurrency. But people aren't computers, we're above having to worry about that stuff.

You know you're on slashdot when... by crucini · 2002-03-15 13:10 · Score: 2

Everything turns into 'the linux solution' vs. 'the Microsoft solution' even if one or more of those is inapplicable.

I wouldn't, however, recommend working with anything from Microsoft.

I don't think Microsoft has any offerings in the serious source control space. They do have a toy called "Visual SourceSafe (?)" but I don't think even they take it seriously. The leader in source control is ClearCase. The ClearCase VOB server is normally run on SPARC/Solaris. The client runs on everything common, including of course NT, Linux and Solaris.

So I'd leave Microsoft out of this discussion and ask whether Sourceforge.* can compete with ClearCase. Or what Sourceforge.* offers beyond ordinary CVS.

Re:You know you're on slashdot when... by xtremex · 2002-03-15 13:43 · Score: 2

Microsoft uses Clearcase themselves! You actually think they use Sourcesafe?? OK, Boss...We just added the new Windows 2004 source code in to Sourcesafe ..oops....the SourceSafe database and registry got mangled! Back to square one!

--
If you're not a Liberal in your 20's, then you have no heart.If you're still a Liberal in your 30's you have no brain.
Re:You know you're on slashdot when... by thomas.galvin · 2002-03-15 13:51 · Score: 1

I'm not a big fan of clear case, but it is the best VCS I've seen.

CC probably has all of the tools this gentleman needs, and since he mentioned it in his post, I would guess they are already using it.

Clear Case has a featur called "rebaselining," where a developer that has a source file checked out can see what has changed on the baseline and merge those changes in with his/her own. Each developer should be responsible for doing this until they submit their changes to the build master/integration guy/prject lead. Once a file has been submitted, it's usually the program lead's job to sort out the inconsistencies when creating a build.

--
Thomas Galvin
Re:You know you're on slashdot when... by tenman · 2002-03-15 14:36 · Score: 2

ClearCase is not a VCS... it's a CMS...

read all about them here
Re:You know you're on slashdot when... by thomas.galvin · 2002-03-15 15:06 · Score: 1

ClearCase is not a VCS... it's a CMS...

We use DDTS for bugs/feature tracking...all we use clear case for is version control and integration.

--
Thomas Galvin
Re:You know you're on slashdot when... by Eccles · 2002-03-15 15:06 · Score: 1

I don't think Microsoft has any offerings in the serious source control space. They do have a toy called "Visual SourceSafe (?)" but I don't think even they take it seriously.

We used it for a while, but gave up on it due to it corrupting files. I have also heard that Microsoft doesn't use it, and if you don't "eat your own dogfood", no one else should either.

--
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Re:You know you're on slashdot when... by tenman · 2002-03-15 15:21 · Score: 2

then don't go to sleep silly boy :)
Re:You know you're on slashdot when... by sadr · 2002-03-15 17:21 · Score: 1

Actually, Microsoft probably uses Perforce, at least on the Windows2000/XP project. (What they actually use is "SourceDepot", but there are no links anywhere on the web to a product by that name, except in some old Perforce Documentation.) See http://www.usenix.org/events/usenix-win2000/invite dtalks/lucovsky.ppt or the google cache for "SourceDepot" for more details.

Although I expect it's difficult to say what they use one thing, since it's a large company and I'm sure parts use Visual Source Safe, and parts might well use ClearCase or CVS.

Subdivide, code ownership, short checkouts by cfulmer · 2002-03-15 13:14 · Score: 2

So this is the only sort of development that we do. A team with 20 engineers is actually pretty small here.

The first thing to do is to divide the functionality among engineers and have the engineers work in their own modules, talking with other engineers to find out what their needs are. That way, one person is responsible for changes to any given file. In addition, make sure that files are *locked* while somebody has them checked out -- ie you can't change it while I do.

Next, people should know about what they're going to do to a module before they check it out -- if it's checked out for more than 1-2 days, it's too long.

And, finally, there needs to be a mechanism to group changes together. So, if you're making a change in the code that requires changes in modules A, B and C, you check out A, B and C, and then you check them back in. That way, later on when somebody wants to compile the entire thing, they know they're getting your full change and not just your changes to A & B.

In any sufficiently-large software project, 10% of the code will receive 90% of the changes. The key is to find a way to serialize changes to that 10% -- the other 90% of the code will probably never be an issue.

Slower? by Anonymous Coward · 2002-03-15 13:21 · Score: 0

Um, how can source control be really fast? I'm not sure how speed is an issue...also, I'm sure you're talking out of your ass, what with the lack of factual data in your post.

Been there, done that. by tlambert · 2002-03-15 13:26 · Score: 4, Interesting

As the author of the original 386BSD 0.1 PatchKit software, I have to say that your "air traffic control" approach will not work.

The 386BSD 0.1 patchkit used a serialization of patch numbers, with central assignment. The reason for this was that the patch dependency management was done by manually applying patches posted to Usenet, and then diffing the modified version of the code against a version with the previous N-1 applied.

Effectively, it was a "human CVS repository" system.

Ir was necessary, because the latency in the Usenet system meant that you couldn't "lock down" a file or set of files for some major change: you had to do what you wanted to do against what you had, which was almost never "the most currnet concensual version" of the code, and then hope someone else didn't win the race to "the repository" (at the time, terry@cs.weber.edu's incoming email, and then, later, Rod Grimes', Nate Williams', and then Jordan Hubbard's... no one wanted it for very long).

This led to all sorts of problems; the major one was that the patch kit format was "reverse engineered" (not hard; the patch tools, except the creation software itself, were widely distributed), and a group started releasing patches in the "1000+" ID range, under the incorrect impression that the concern was over the patch namespace collision, not topological application problems. This eventually led to a big argument, and other people going off to play in their own sandbox.

You've probably heard of "NetBSD". A couple (not all, of course) were motivated by communit rejection of the 1000+ numbered patches, which, while they were not colliding in serial number space, seriously blew out topological dependency space for modified files.

In any case, that's exactly what you are doing with your code, when you plan on assigning patch numbers based on expectation of completion.

With the number of people you have, the comments about contested interfaces being agreed to beforehand, and the comments about you having no real problem here in the first place are probably accurate.

You can basically take a couple of approaches.

The first is: don't accumulate patches, just check the code in. This respolves the problem of stale patches by not permitting them to become stale in the first place.

The second is: "cvs tag" before any major commits, so that there is a baseline from which to work to resolve conflicts.

Really, you should not be accumulating large patch sets, with as few people as are involved.

If you have a huge offline latency from a developer or group of developers (e.g. you send a CDROM to Antarctia, and two months later the send back a CDROM with their patches on it), or if you have a huge number of developers, you should reconsider your chioce of tools.

The 386BSD patchkit serialization of patch sequence numbers through a couple of human beings was a serious mistake. It had the emergent property of having a tiered set of priviledge. I'm convinced that this is what resulted in the current "core team/committer/less-than-dirt" striation in the BSD camps today.

I mention this, because CVS has a similar, though somewhat less profound, emergent property of "The One True HEAD Branch". By its nature, it encourages a single direction for all experimentation and all forward looking thought, denying nourishment to any contradictory lines of inquiry, by chopping off the roots. CVS is, in a nutshell, anti-research. It prevents people from going off 90 degrees from where everyone else is headed, and discovering new territory.

Perhaps you've heard of OpenBSD. It emerged because there was "One True HEAD Branch" in NetBSD (an early adopter of CVS, in Open Source-land), and several people felt strongly enough that the focus of the project should be secure systems research, that the resulting code directions were incompatible.

Tools issues are at the base of nearly any strong divide you can name in an Open Source community.

Linux currently has issue, where Linus is investigating the use of Larry McVoy's BitKeeper (Larry was smart, in that early on, he recognized the emergent properties tools choices force onto projects, and tried to design around the problem). It turns out that a single human CVS repository doesn't scale infinitely.

FreeBSD is in the throes of a "To use Perforce or not to use Perforce" decision. Perforce supports seperate lines of concurrent developement.

It fosters, as my former boss' boss, Ray Noorda, used to say, "coopetition": help each other make the best implementation according to their design, and then may the best design win.

Perforce lets this happen, but it also tends to balkanize developement, if not everyone is using the tool. There are complaints in FreeBSD that significant work is taking place in Perforce branches that aren't visible to normal CVS users. The Perforce users complain back that there would be no need for Perforce, if the develeopement were permitted in the main CVS tree -- along with the breakage that would entail. Both arguments have merit. Right now, there is a truce... more of an agreement to disagree, and not force the issue today, but a promise that the battle will be fought to the death at some later date.

For your project, a tool which supports multiple concurrent "One True HEAD Branches" seems like it fitys the bill (though as I wrote that, I still asked myself why, with so few people, it was an issue for you in the first place).

Whether the tool you pick is Perforce, Bitkeeper, or some other tool that can support that developement model is irrelevent.

What is relevent is that you understand that our tools shape the way we think about solving problems, and if you have already arrived at an approach that doesn't -- or *can't* -- fit into the shape dictated by CVS, then it's probably time to look at another tool.

Not matter what you do, I can guarantee you that layering another, less adequate, tool on top of an already inadequate tool, will not fix your problem.

I can also guarantee you that if you can't change your model to fit an existing tool, you're going to find yourself in the source code control tools business, instead of the business you intended to be in.

Probably, you should rethink whatever premise it is that's resulting in large, infrequently integrated patch sets. If it's just your release engineering department not wanting to do their work on a branch, well, that's tough. Branch tag for releases as a matter of policy, and move on. If on the other hand, it's something more profound, perhaps you need to rethink your assumptions in favor of what the tools can do, vs. what you would like them to be able to do.

Alternately, welcome to the source code control tool business.

-- Terry

Parallel Development by HalB · 2002-03-15 13:31 · Score: 2, Insightful

Okay, I think 90% of the people responding are missing the heart of the question. The original question was about parallel development, not just working on small changes in the same source tree and then synchronizing in the changes.

The best way to solve this problem is by better design of the software. If your software is well-designed, you the only time you really need to do parallel development is when you're maintaining multiple versions of the software. (i.e. service pack 1 and 2 to windows 95, while you work on windows 98 elsewhere).

The way we solve the problems above is by using a task-based change management solution. We use a commercial product Continuus/CM (now Telelogic/CM) to handle both the parallel release maintenance problem, and the manangement-didn't-enforce-good-design problem. This problem can be exacerbated by having almost random changes in the requirements combined with very tight deadlines. Fortunately, having a task-based CM tool lets you roll with the punches.

In task based change management, groups of file changes are grouped into a task. This task is one unit of work, something like "change product name string from a character string to a unicode string" which may involve touching several files. These file changes are brought in (or excluded) as a whole - the whole being a "task". Integration test approves "tasks", and if a developer wants a task before it has been integration tested, s/he can bring it in manually, and get all the updates.

This allows a group to work in parallel with the main effort, by including groups of tasks themselves that haven't gone through integration test (perhaps because they don't work yet, other developers' tasks are needed, or it's just a large change requiring more people to work on it before it can be tested).

Merging is done when needed, this way. One thing you can do in this program is "show conflicts", to show you what merges need to be done - on your parallel development effort, not the rest of the tree.

The merges never really get confused if you use a decent merge tool (we use tkdiff). The only time you would have problems is if everyone is rewriting the file to be merged from scratch every time... And in that case, the sofware design problems are so bad you really can't do anything about it.

The Continuus/CM software, however, is very costly. I think BitKeepr does some of the same things, but unless your company is one which doesn't mind its company secrets being posted to the web, you will have to pay for that too.

aegis is another free tool you might look into. It doesn't have a GUI, though.

It needs to be inherent. by agm · 2002-03-15 14:06 · Score: 1

Source control needs to be inherent in the development environment you are using. Relying on third-party tools or add-ins to successfully manage multiple developers in the same project is a mine-field.

The IDE we use is called Jade (www.jade.co.nz) and is a OO database. The beauty is that the IDE is written in Jade which means that the classes, properties and methods are actually objects in the database. Handling for mutliple developers at once is a breeze as the system does it all for you. We have 10 developers updating and managing a 1,000,000 lines of code project with ease.

I know the pain by cvanaver · 2002-03-15 14:13 · Score: 1

I've been the lead techical achitect on a corporate systems integration project (fluctuating between 20 and 80 developers) for almost 2 years now, and though I'm not the version control expert, (we use ClearCase and I've learned to become pretty competent in release management) I've definitely understood the pain that comes when you have merge conflicts. Because we use exlusive locking in our files, the issue only comes up most prominently at bug-fix time when we branch the tree to do production fixes and have to re-merge.

The best solution we have come to is in pure communication. We divide all developer actions into developer-defined ClearCase activites, and for every activity we not only log our changes in CC, but also send out emails to the group mailing list detailing the nature of the activity and the files changed. This definitely has encouraged active communication within our developer group and resulted in far fewer migration/release issues.

If the developers are talking to each other through a structured process, they can resolve issues informally and ensure that code meshes. Currently, are comm. processes are manually, but we are looking at CC triggers to automate the process.

Perforce Version Control system by jalagl · 2002-03-15 14:18 · Score: 1

At work we normally use Visual SourceSafe, which, at least in my eyes, has a lot of problems and is definitely not suited for distributed programming.

Recently, however, Ive been using Perforce quite a bit, for a project in which we have three geographically distributed teams (Costa Rica, Utah and California). It is really nice, especially compared to VSS. It is completly multiplatform, very stable, has a nice interface (both winP4 and the command line client), manages branches and merges really well, etc. The only downside I see is that access times are a bit on the slow side, but then again, all of them are here in Costa Rica ;)

We also used CVS a little bit before switching to P4, and it worked well, but I think P4 is a more polished product, specially since not only developers where checking in and out stuff.

--
-.

Re:Modular Isolation - Is it really a good idea? by Anonymous Coward · 2002-03-15 14:19 · Score: 0

I disagree. Big time.

If you seperate your development team into these modular areas, then no one is sharing knowledge in your team. That is a VERY dangerous situation for a development team.

The result it that you have these little areas of code that only one person knows about. If that area of code happens to be vital, then you better pray that the one person who knows about it doesn't get a better job. Or doesn't get run over by a truck. It DOES happen!

Setting up a development team in such a fashion is not only dangerous, I think it is irresponsible. There is too much potential for the company to have to spend extra money to make up for losses of these "towers of knowledge."

Not only that, you also state that you should do all this planning in advance. Very rarely are you able to completely plan everything out about a project in advance. And even if you do, things change, or there are things you missed. How are these little bumps in the road handled if you have such a restricted paradigm.

I have been working in XP (extreme programming) environments for 2 years now on 4 different projects, and I find it very refreshing to be able to go fix a bug that I run across in the code, regardless of who wrote it or is working on it at the moment. Who cares if that file happens to be being worked on at that moment. There are some great tools out there for merging in the fixes. CVS, ClearCase, BitKeeper...

The key is having a disciplined team who is constantly updating their local version of the code base and checking in their changes frequently. Merges do come along, but they come along less often, and they are smaller if you do frequent checkins and updates.

My 2 cents

ENVY by Anonymous Coward · 2002-03-15 15:47 · Score: 0

Has anyone seen ENVY for something other than Smalltalk or VA Java?

Actually Use CVS by sdowney · 2002-03-15 15:59 · Score: 2, Informative

The poster seems to be contemplating a system such as Linus used to use to manage the Linux kernel. People would submit patches to Linus, and he would attempt to integrate them into his source tree.

This is a dumb way to manage a project. It barely works for Linus. And he's a genius.

The right thing to do is to give your 12 developers access to the CVS repository. If they are geographically separated, use a VPN or ssh to connect to the repository. When they finish their work, they first update their local workspace, compile and test, and if it passes, commit their changes back to the repository. Other developers get the changes as soon as they are available.

Twelve developers is the leading edge of a small project. You can have a single team, and everyone can be aware of what everyone else is doing. The best process is the one with the minumum of overhead that suffices for the project at hand. Don't add process for the sake of process.

On the other hand, don't sacrifice the basics.

Version control is not 'Advanced', it's fundamental. You might as well say you're using advanced visual editors, such as vi. SCCS is from '75. RCS is from '82. CVS is from '86. This isn't new stuff.

perforce by maraist · 2002-03-15 16:20 · Score: 2

I've used clearcase (great tool for many things, but slow and expensive), cvs (cheap, functional, but frustrating at times), and perforce. For those that don't know, perforce is commercial but not that expensive.

perforce makes use of sequence numbers for just about everything.. It uses RCS as the backend, and berkley hashtables for a database. Unlike CVS, all files are initially read-only, and you have to "edit" a file (register an edit with the server). This along with the database provides very extremely fast revision-control operations (diffs, checkins, updates, submits, etc).

perforce has a really sophisiticated branching system (I found a few nifty advanced uses for it, though I wouldn't recommend getting too creative like I did). There is a free version of perforce that only allows a single user. Doesn't allow multiple branches or anything either... But if you're a business, then I'd definately suggest that it's worth it.. It's all the advantages of RCS/CVS with only the problem of cost. (I think it's $200/head / year).

In general, however, you really should establish a commision process... We typically have multiple branches dedicated to different aspects of development.

Each developer gets his/her own branch.. Then there's an integration branch.. A single human being has access to the integration branch.. It is his/her responsibility to take in the changes (from a posted commit number) from each developer's branch and bring into the integration branch.. That branch should then run through sanity testing (to verify more than freedom from conflicts). Finally when everybody is happy, the integration branch gets merged into the main branch (as a form of release).. At each stage, commit labels shbould be applied (for further backtracking).

-Michael

--
-Michael

Re:Extreme Programming -- For fools by sadr · 2002-03-15 16:40 · Score: 1

XP says that you should pick a subset of the requirements that are known at the present time, and design exactly as much as needed to implement those requirements. Then implement that design.

Then you pick some additional requirements, and modify the design and the code to meet the combined set of requirements.

Repeat until management says to stop (or you run out of requirements.)

If you have no requirements, XP says you're finished.

And you update your design as requirements are added and changed, which frequently doesn't happen in a design up front approach. No one wants to go back up the waterfall, and then start over with the code. (And without requirements and design expressed as executable tests, you do have to start over with the code every time you make major changes in the design.)

CVS Watch is your friend by moooooooo · 2002-03-15 16:40 · Score: 1

generally two developers shouldnt be modifying the same function or even the same file, but if you use cvs properly then you can be notified via email if someone else checks out a version of the file you are working on. cvs watch does this, look it up in the manual.

Then all you do is contact the person and ask them what they are doing.
It's all about communication and good project management.
cheers
peter

Linux doesn't use CVS by nixnixnix · 2002-03-15 16:47 · Score: 1

I heard that Linux Kernal doesn't use CVS, they use a simple tree. Linus has his tree, Cox has his. They share their diffs. Very Zen.

rational by zoftie · 2002-03-15 16:48 · Score: 2, Informative

It seems XP is taking over masses of programmers that love to code. Rational is for pseudo programmers and managerial types who have weak analytical thinking and often like to fall back onto diagrams. UML is no slouch, but it is often used to conceal ignorance and laziness to undestand technical underpinnings of a system.
UML is good, but as many things it is often misused.

Rational software not one I would use, but it should work considering all developers are on the same page. Tools should be used to get understanding of system being built, not building system like lego toys, slapping a schedule on imlpementation and stilling back and relaxing.
Revisions to diagrams are often painful, because you often have to explain just basic things, and gut feelings to managers who do not care, and can't understand what you really mean. Often enegery is spent on changing diagrams around and talking to pseudo programmers, than implementing quality code.
Any methodology can be great, but only if management believs it in, keeps everyone on same page and makes process a development and understanding tool, rather than programmer control tool - which often happens.

I suggest using bitkepper or CVS in combination with automatic documentation generators(Doxygen?).

merge early, merge often by Anonymous Coward · 2002-03-15 16:58 · Score: 0

Microsoft follows the "merge early, merge often" policy detailed quite clearly in the book Microsoft secrets. Its a 2 step process - do a merge (as often as possible), and immediately after doing a merge, check it back in and see if your merge has not broken the build. The person who breaks the build then remains the build manager who maintains "shippable" version, until someone else breaks the build...

Fire your Software Architect ! by Jeb+Beckman · 2002-03-15 16:59 · Score: 0

If the developers are modifying the same header (*.h) files often, the solution is to "fire your design architect". Your chief architect obviously has little experience partitioning a software system and dividing up the workload.

Which shopping mall do customers frequent? Large software projects are like building a mall. Do customers goto the mall built by skilled brick layers (programmers)? No. They shop at the mall designed by a qualified architect AND skilled brick layers! Fire your architect before it is too late.

Re:Fire your Software Architect ! by Jeb+Beckman · 2002-03-15 17:21 · Score: 0

If you would like me do some architectural consulting for your software company, then drop me a line. If you wish to be a "world class" software company, you must build the best products on the market. That is who you are competing against. Drop me a line.

3 Way Merge? by sadr · 2002-03-15 17:00 · Score: 1

What it sounds like you're missing is referred to as a 3-way merge.

When merging 2 different code branches, you need the parent from which the two branches started, and the final version in both branches. Then you take the changes between the parent and one of the new versions, and push it into the final version of the other codeline.

The tool we used at my last job for version control was perforce (www.perforce.com). A company called Araxis makes a great 3-way merge tool for Windows that integrates with it nicely. Perforce prevents you from checking in a change until you resolve the merge with the latest version checked into the system. And it doesn't allow any of the files to be checked in until all of the files are merged. (Atomic Changelists.)

If someone has to re-apply a patch multiple times, something is seriously wrong. The other developers are not correctly applying their patch to the latest version of the code, and are instead overwriting it. This is malpractice on the part of the other developers.

CVS automerge sucks. The TRUCK is RED. by Jeb+Beckman · 2002-03-15 17:08 · Score: 0

Which is correct? The following same line of source code exists in two copies of the same program file. Resolve the ambiguity!

Line 10 - "The TRUCK is RED"
Line 10 - "The CAR is BLUE"

Resolve line 10 with "automerging". Cannot be done. Automerge sucks!

You are using ClearCase like an idiot by Anonymous Coward · 2002-03-15 17:17 · Score: 0

All developers should work on the same branch to take advantage of winkins and to reduce merging. Read the man pages on clearcase config specs and learn about time stamps to prevent your code from shifting beneath you while you work.

From an ex CM Consultant by billsharer · 2002-03-15 17:25 · Score: 2, Insightful

Boy this opens a real can of worms for me. Caveat Emptor: I used to be an SCM consultant under the employ of a company formerly known as Continuus software. It is now a part of Telelogic AB. FYI: I am Yet Another Laid Off Person (YALOP).

First. If there's only a dozen of you, and you have a branch, perhaps you should talk. Now if you were like some of my former client base who does follow-the-sun development around the world, this gets a little hairy. By that I mean a company like a TI or BT or Philips is passing code around the world and flexibly allocating resources from multiple sites to a project. Serious commercial SCM systems like Continuus/CM, err.. Telelogic CM/Synergy with DCM and CC with Multisite can be used to coordinate. This is one place that open source has failed to penetrate due to the small size of the potential market and the general antipathy that the average developer has to the CM people. Until, that is, they get religion by losing something very important at a crucial moment ;-) Even then most shops can get by with VSS or PVCS.

OBTW: I'm an ex-developler, system admin, desktop video weenie and computer consultant that backed into SCM. I got religion back around the late 80's but it was pre-emptive. Anyway, concurrent development actually comes in three flavors: concurrent by collision, concurrent by release (patches versus next generation) and finally concurrent by platform (Windows vs Unix, etc). Each is handled differently and under different timeframes (including permanently in the latter).

Your post alludes to the first case of a "popular" file that needs checking out a lot like a header file. In a shop your size, this should be handled by parallel checkout notification (a common feature in commercial high end systems) and hopefully a bit of coordination by phone or shouting over the pod wall. If you are in severe RAD mode, I suggest using a shared work area to enforce sequential checkout. Your SCM tool does build a work area doesn't it? If not, hit yourself on the head and ponder why people like me are now on the dole.

Okay, so you decide to branch anyway since you or the other developer are really going to break things with a rewrite. Hey, wait a minute! Shouldn't a big feature change (or small) be considered as a single unit of work where all of the files changed by the feature get moved through the mill at once. You have just re-invented the wheel known as Change Packages, Task Based CM, ChangeSets and whatever else the marketing wonks are using nowadays. Once again the high end tools have this (or should). Continuus had it back around 1997. Rat got it into CC much more recently, but there it is.

If you have a task based system, it makes life much easier to do merges and to put things in or take things out of the build. Being ex-Continuus, I could pound the pulpit about how build managers can check the configuration and its set of included tasks for consistency, but I won't. Instead I'll just mention that graphic history views and a decent merge tool that takes into account ancestor versions should take care of any merging issues.

One more thing. The sooner you catch the branch and do the merge the better. Don't punt it to CM unless they are ex-developers who know the product as well as or better than you. You may also come to find that an integrated Change Request Management system like ChangeSynergy for Continuus (err Telelogic) and Clearquest for CC become very important in your life.

--
Our Corporate Mission: Strive to slack off much more efficiently

I am a Configuration Manager. by ACK!! · 2002-03-15 17:28 · Score: 2

I use to be a Sysadmin. The deal is with CVS is that as many other people have noted merges are not so much an issue if you do your updates regularily in your workspace. Unless the project is really small 2-5 programmers or so most people know that they can working on files in the same module as someone else. When the programmer is ready to unit test it is vitally important that they update. Also regular check in's along the development path is also very important.

Remember also, that the use of tags for marking the progress of files in development from a code ready to test ready to integration ready status is very important and as for remembering cryptic commands that is why you need a technical person and not a corporate type as your CM because all it takes is a few shell scripts, perl scripts and web interfaces to simplify tagging files and looking over the CVS structure. Hack CVSweb that is why its there.

_________________________________

--
ACK /ak/ interj. 2. [from the comic strip "Bloom County"] An exclamation of surprised disgust, esp. i

Parallelize by ryochiji · 2002-03-15 18:38 · Score: 1

I don't have much experience with concurrent development involving many programmers, but the problem seems to be similar to that of parallel computing. In other words, the difficult part is probably in how (and whether) the tasks are split up. If each programmer is given a task that doesn't rely on (or interfere with) anybody else's task, you have a more efficient parallel process. In fact, it's probably possible for some projects to have a "coarser grain" than others, and trying to parallelize such projects might just make it more inefficient.

So the question really should be "how to split up projects efficiently" and not "what tools will magically streamline a poorly managed project?"

--

---
Open Source Shirts

OMFG, do you guys not have a dev manager? by Assmasher · 2002-03-15 18:52 · Score: 1

That is NOT a big project. Try 80 devs working in the same source code with multiple builds from the same common source base on both IRIX and NT/2000?

Source control on large projects is TRIVIAL. You just need very specific check in procedures... That's it. People who don't follow the check in procedures just need to get hammered :).

--
Loading...

checkout notes by Just6979 · 2002-03-15 19:58 · Score: 1

upon checking out a file from a CVS repository, require the person checking them out leave a little note as to why. probly applicable to entire modules as well.

-- justin

--
--Justin

continuus by devonbowen · 2002-03-15 20:38 · Score: 1

Not sure I fully understand the problem but you might want to look at Continuus. It's too complex for small teams (2-3 people) but not bad once you cross the 10 people mark.

Changes in Continuus are grouped into tasks. So a task might be "add a back button to the browser". Each developer in the group checks out the baseline code and works on his tasks. This environment is then protected from anyone elses work. When a task is completed, it is checked in as a group of file changes but does NOT immediately go to other developers. Instead, a build manager comes along at some later time and merges the tasks and verifies that they pass some quality assurance tests. Only then are the tasks available to the rest of the programmers in the group.

It doesn't need to be as rigid as I've described here. For example, I can include your task in my development even before the build manager approves it. Or I don't have to update my environment with the new tasks even if the build manager has approved them.

But that's the basic philosophy. Essentially, separate the development and quality assurance into two different jobs. This keeps environments clean until you can trust them enough to move along.

Devon

Developers need education more than new tools by MSG · 2002-03-15 20:48 · Score: 2

As pointed out by others, your problem is clearly that your developers are not doing a 'cvs update' before they 'cvs ci'. The tutorials and HOWTO's recommend this consistantly. Otherwise, you end up patching *out* what another developer patched *in*.

Have your developers read the CVS Book: http://cvsbook.red-bean.com/. If it helps, consider buying a copy or several. Helps the authors, and makes good reference for your developers library.

What about Aegis? by __aasmho4525 · 2002-03-15 21:17 · Score: 2, Interesting

i've searched through the threads on this article, and i'm ABSOLUTELY SHOCKED that not one person has mentioned Aegis. i have used cvs since it's earliest days, and rcs prior to that (not counting a number of commercial offerings), and i must say, i despise it greatly. i find it to be EXCEEDINGLY clunky at managing concurrent development of FEATURES THAT YOU AREN'T CERTAIN ARE GOING TO MIGRATE TOGETHER INTO PRODUCTION.

see, in my experiences, when dealing with huge software systems, it's rather tough to get all DEPENDENT changes to move in lock-step with your own project's changes when the problem is rather large. given that, we end up having to create branches & associated tags for EVERY FEATURE which we then merge all around into release-branches, which all just becomes a rather kludgy mess. the time spent on source code control begins to grow exponentially, and the skill required to do this safely grows with it.

Aegis solves these problems like the commercial configuration management tools (clearcase, PCMS/PVCS, etc, etc) in that it allows for deltas to code to be aggregated together and considered as one atomic change (many times relating these together as implementing a specific managed change (say from a bug-tracking system, etc)).

this is ABSOLUTELY NECESSARY when you have hundreds of software developers on a project in my (admittedly limited in the grand scale of things) experience.

i've always been shocked that so many open source developers were simply willing to put up with cvs given all its warts.

hopefully this article and the discussions surrounding it force some folks to stand up and demand that the "state of the art" be advanced. (i realize that the state of the art is really far beyond what cvs does, but cvs HAS MIND SHARE).

btw: aegis is GPL'ed and has been around for a LONG time. in addition, it's core concepts are similar to almost every other CM tool i've used (even including cvs, not counting the advanced features) so most people can get up to speed with it quickly.

i'm also confident that the SIMPLER aspects of source code control / configuration managment could be integrated into most IDE's by building cvs-command-compliant wrappers around Aegis if the time-to-market for the integration were deemed more important than a native integration...

oh yeah, last thing: aegis heavily entices you to check in test cases for your code. i've found this to be a simple but effective mechanism to aid people in building good regression test suites...

i'm curious to see whether i'm alone in my opinions on these topics or not...

cheers

Peter

Try another piece fo software by Voxol · 2002-03-15 21:31 · Score: 1

For my disertation I wrote a system that locked specific lines in files and then used set theory to manage locking.

The next step from there was to detect when one function/method relied on another holding still and then deny locks on the later until the former had finished development.

There were other rules with timeout on locks and stuff but I hope that explains it.

Culture by cheezehead · 2002-03-15 21:46 · Score: 1

Oh boy, where to start...

First of all, let me make clear that I don't have any real experience with CVS. My main practical experience is with Rational ClearCase. Free plug: this is a very powerful and sophisticated tool, which will allow you to set up your own customized CM procedures. Branching, merging, complex checkin/checkout rules, triggers to that can be fired on any action, it has it all. It has this extension called MultiSite, which will allow you to do geographically distributed development. Basically, it has all you can imagine. Especially the UNIX version is very stable. So much for the good news. The bad news is twofold. One, it's kind of expensive, especially when compared to CVS. Second, because it is so powerful, you need a ClearCase expert on your team. Quite an investment, especially for small teams.

Which leads me to conclude that for a team of a dozen developers, it is probably overkill. Unless your project has money to burn, you probably can't justify buying ClearCase licenses.

Aside from that, reading your problem description, I'm afraid you have a culture problem on your team, that can't be solved with CM tools only.

First of all, a dozen developers isn't all that many. If you have many checkin and synchronization conflicts, it seems to me that your developers aren't talking to each other. Some years ago, I worked on a control system for the European Space Agency. We had about a dozen developers (a bit fewer in the beginning, a bit more at delivery time), and we managed to keep schedule slip to 2 months on a 24 month schedule. I think this was mainly achieved through intense communication between developers. We used a very primitive CM system (only checkin/checkout, no branching/merging), so that was not the silver bullet.

Tangent: some years ago I read a story about product development at Borland (I think the product was some version of Paradox), where 15 developers successfully developed the product almost on budget and schedule. The interesting part about the story was that the team spent approximately half of their time on meetings!

Anyway, the second problem (I think) that you have is that you are probably working from a poor design. A proper design, whether object-oriented or not, will partition the system into clean, cohesive, loosely coupled units/modules. Developers should not get in each other's way in that manner.

A third problem is universal: us programmers are free spirits. "We don't need no stinkin' control, we know what we are doing!" Wrong! It continues to amaze me that people easily accept the fact that they have to come to work every day, but they don't seem to think they need to follow CM procedures (or coding standards, for that matter). Part of this problem is that you'll get sacked for not showing up, but not for violating procedures.
The fact that you hint that checkins happen at the last minute before the deadline is sort of worrying. The attitude should be: checkout, make change, test change (!), and checkin as quickly as possible. Small, quick changes. This has the side effect that you have more checkpoints to revert to. Also, any change you make is invisible to others until you check it in! Want your changes to be in the baseline? Check in as soon as possible, or someone else will beat you to it.

I could go on and on, but bottom line is this:
- have a CM procedure
- make sure everyone is aware of it
- assign (only) 1 or 2 persons to make baseline changes
- let the CM system enforce the rules.

- and of course, have a design...

Just my $0.02...

--

MSN 8: Now Microsoft even has bugs in their ad campaigns.

WinCVS no good by Walles · 2002-03-15 23:13 · Score: 1

In my personal opinion, WinCVS is far more complicated to use than the ordinary command line client. It *looks* nice, but that's about it.

If you want a graphical shell for CVS under Windows, I have heard good things about TortoiseCVS. I have no personal experience with TortoiseCVS however, so whether it is actually better I really cannot say.

Best thing is of course if you try 'em both out and see for yourself.

--
Installed the Bubblemon yet?

Opportunity cost of spending 30k on source control by Anonymous+Brave+Guy · 2002-03-15 23:40 · Score: 2

Perhaps by large company standards, $30k is modest. You can even justify it with arguments of how much employee time it will theoretically save. OTOH, it's still, in absolute terms, a lot of money for a small company. The question is not just what benefits would you derive from investing that $30k in source control, but also what alternative benefits could you derive if you went for a cheaper option and invested the remainder elsewhere?

If you went with, say, CVS+WinCVS (which also hides much of the command-line complexity cited earlier in this subthread) then you have a total cost of pretty much zip by comparison. That leaves $30k to spend on something else. Would hiring a part-time office assistant to deal with the paperwork also save your developers at least a week of time over the year, for example?

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.

"Rebaselinining" (or whatever you call it) by Anonymous+Brave+Guy · 2002-03-15 23:46 · Score: 2

/me points out that you can do such three-way merges in many other tools as well, albeit without the nice buzzwordy title for the feature. We routinely do exactly what you describe with CVS and accompanying tools, for example.

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.

CVS does these things! by Anonymous+Brave+Guy · 2002-03-16 00:00 · Score: 2

As far as I can tell, CVS supports, or provides a direct equivalent to, everything you mentioned.

File locking is supported, unsurprisingly via cvs lock. We use this routinely for "binary" files, such as bitmap files or docs, where naive merging of changes doesn't usually make sense. If you lock a file, and someone else tries to lock it, they get a warning back. As long as you routinely go through an update-lock-edit procedure before modifying any of these files (NB: one line of script used instead of cvs edit does that on most systems) there is no problem here.
I don't understand your "code promotion" idea, but it sounds like what we routinely do anyway: branch your code when a release is looming, continue development on the trunk, and just merge bug fixes across onto the branch as necessary.
CVS supports tagging, which seems to be exactly what you need for "build labelling".
All check-ins are atomic, and committing files from all over your source tree is easy with something like WinCVS' "flat mode".

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.

Re:CVS does these things! by brucet · 2002-03-16 16:22 · Score: 1

All check-ins are atomic, and committing files from all over your source tree is easy with something like WinCVS' "flat mode".

Each file's checkin may be atomic, but if you got an error halfway through checking in a set of files, the first files will remain checked in and the code tree is in a invalid state.

This is one of the problems that Subversion intends to fix.

-Bruce

Just play by the rules. That's all it takes! by cookd · 2002-03-16 00:36 · Score: 1

Make sure that your process includes the following, and your development system will scale well (assuming that all else is ok):

1. Your source control system should warn you if you "check out" a file that is also checked out by someone else. You can then judge how much you are going to change it, and if necessary contact the other person for coordination.

2. Update often. Keep an eye on what is changing. If things are changing in areas that you are playing in, skim through the changes to make sure they don't affect you.

3. Update to the latest version of everything, merge any conflicts, build clean, do a quick test of the product (especially in the areas you were working on), get a code review from someone else, and THEN check in. You should probably get somebody else to update, build, and test immediately after your checkin, in case a random disturbance in the force allowed things to work on your machine, but it really has a problem.

4. Set up a nightly "official" build. In the morning, run through a standard set of tests on the "official" build. This helps avoid regressions.

5. Provide lots of pizza.

--
Time flies like an arrow. Fruit flies like a banana.

Process vs. Tools by msheppard · 2002-03-16 01:55 · Score: 2

My Names's M@, and I use Source Safe... *Hi M@!*

&ltflame reard&gt
Yes, we are a microsoft shop. Hence source safe. I am curious about all the talk about TOOLS in this thread and not as much attention to process.
&lt/flame retard&gt

I imagine it is possible to manage the process without any real off the shelf tools... keeping a backup or huge levels of cascading directories. Couple with a REALLY good, well defined, and well followed process, couldn't this work? I'm not suggesting it be done, but explored as a hypothetical allowing one to discover the nature of the beast much better.

And RE: "Source Safe Sucks", it's just a tool... it should be possible to use it correctly coupled with process to solve the problems.

BTW: I'm very glad to see this thread... I dunno how many times I've searched for this information.

I'll be checking out (no pun intended) SourceForge, but I'd like to hear mention of maybe more books (chekcing out the extreme programming as well)

M@

--
Krispy Cream is people

Re:Process vs. Tools by sadr · 2002-03-16 03:50 · Score: 1

There's a really good comment up above about how the capabilities of a tool can influence the character of a development process. But as to why you need a tool at all...

In my development paradigm, you need a new branch every time you want to have a different criteria for checking in files. For example, an old code release that only gets security bug fixes would be one branch. A set of code sent to QA might be another branch (and it wouldn't change until QA was ready to test the next candidate.) A developers work area might be a third branch. And the latest and greated development baseline (which is always guaranteed to compile and run regression tests) would be another.

Inevitably, you end up having to merge changes between branches of different policies. Sooner or later you have to push the baseline into QA. And after QA, you have to push a single security fix from the latest and greatest code into that really old release. Managing all of this without tools would be absurd.

As far as how software process interacts with all of this, it defines the policy for each branch. Your process will define if you have a development branch for each feature, or if you just have a main baseline everyone changes. Your process will define when a code change is allowed to be checked into the main codeline. (i.e. when it compiles or after it passes regression?) You process will define how shared artifacts (libraries, etc.) get updated and released into actual products.

And then you have to pick a tool that can handle your software process requirements now and in the future.

P.S. One of the biggest problems with SourceSafe is that it isn't very safe. File corruption is fairly widely reported and it is not immediately detectable. That's just utterly unacceptable for something as critical as the version control system containing hundreds of thousands of dollars worth of effort.

I've found in my experience... by joto · 2002-03-16 02:06 · Score: 3, Informative

...that the best solution to this problem is that your fellow developers are in an office across the hall, and that you can walk into their office and talk to them about the changes.

But that doesn't scale... So you've got to modularize the project so that each team works against their own baseline. Any changes that you do to another teams part, must be given to them, for them to check out, and integrate themselves. The important thing is communication, it often happens that they are working on fixing the same problem, but in another and better way, and can give you back their fix instead.

So when you're having problems with your revision control system, what you are really experiencing most of the time, is problems with communication.

Ideally, all developers should be in the same building, they should work at (mostly) the same time (normal office hours), and they should all be friends, and keep a list of each others telephone-numbers, and eat lunch at the same time. Development should be split into projects (having 10-50 people on each project) that are mosty independent. All the people on the project should meet weekly, and discuss their project, important changes, etc... On each project there can be one or more teams, each consisting of four to eight people, who should have offices really close to each other. On each team, development should be split into sub-teams, consisting of 1-3 persons (depending on difficulty and experience), who should share an office, and thus communicate even further. And just as important: this should not be formalized (at least not too much). People should rotate around somewhat, not being stuck with the same people all the time, to get them to know other parts of the project, and other people to communicte with.

The important lesson I am trying to give is that the most beneficial communication, is often the informal. While having a tool help you with managing deltas is surely helpful, it can't solve every problem in the world. You need to work together, but you also need to modularize, and most importantly, you all need to be friends...

Build Leader by cabrandt · 2002-03-16 03:08 · Score: 1

At the places I've worked that have the multiple developer problem several things were apparent:
1. Use of versioning mandatory.
2. Multiple hourly builds present too many problems to other builders. It usually shows an environment where insufficient testing is done.

The only way out is to control checkins. Generally speaking, a team leader / build leader approves or disapproves checkins. Note that this is only necessary in crunch times but checking with others in yhour team is still a requirement. Don't forget, in teams of under 7 or so, you generally know whats happening.

In several embedded development worksites, it worked pretty well if certain developers "owned" resources -- noone else accessed thos devices. If I needed a special access routine to X's floppy, X would provide it.

ClearCase? Leader building an SCM empire, maybe... by jerdenn · 2002-03-16 05:09 · Score: 2

The leader in source control is ClearCase.

ClearCase? Perhaps they are the leader in raising TCO in SCM solutions (and no, I meant maximizing TCO, not lowering it) - ClearCase is great if you are a Software Configuration Manager (which I am) and you are trying to build your 'empire'. ClearCase typically requires a full time administrator, and for many shops, and entire team - Compare this to other toolsets (perforce) that are much lower maintenance. ClearCase requires expensive hardware, fast networks, and bloated clients.
ClearCase does allow some amazing things in the world of branching / merging, but if you are in that 80% of typical CM users, you don't really need all the bells and whistles. Yes, they are nice, but is it really worth the TCO?

-jerdenn

Check the cvs watch command by Anonymous Coward · 2002-03-16 12:56 · Score: 0

It allows you to get notified when someone commits a file as well as some other things.

Alas it's not mentioned in the manpage. But you can have an overview here: http://www.cvshome.org/docs/ref.html

Re:Extreme Programming -- For fools by alext · 2002-03-16 14:39 · Score: 2

Yes, this is valid in some situations. However, there's no guarantee that an incremental requirement has an equally 'incremental' cost - adding security or resilience or some other pervasive aspect to an existing code base rather than doing up-front design cost increase costs substantially.

Agility requires Abstraction and Automation - if you're forced to mix different implementation aspects in the same piece of code (persistence, security, communication...) then be prepared for some cost bumps on the development path.

Re:Extreme Programming -- For fools by ebh · 2002-03-16 17:40 · Score: 2

Um, maybe I don't have extensive enough knowledge of XP, but I don't remember it ever saying that. Tests are written by testers, code is written by developers. On the last project I managed, I took the assignment only because my management guaranteed up front (and kept their word) that developers would never be asked to write any of the tests.

I insisted on this because developers and testers are at cross-purposes: The developer tries to prove the code works; the tester tries to prove it doesn't. You can't do both in one brain.

Oh, and we were able to have the tests ready at the time the code was ready, primarily because developers and testers coordinated between themselves exactly which new features would be worked on when. It worked both ways. Sometimes the testers followed developers' leads, other times the developers coded what the testers were more ready to test.

Note: I'm no XP evangelist. It has some neat ideas, but many of those don't apply well to really large projects, or mature projects with a lot of legacy cruft to work around, and it doesn't work well when you've got one guru for every two slackers and five rookies.

And the name made me immediately think of those guys on snowboards in freefall, hacking on their laptops while doing all those loops and spins.

Re:ClearCase? Leader building an SCM empire, maybe by Kyril · 2002-03-17 02:56 · Score: 1

The only big resource ClearCase really needs that a two-year-old setup wouldn't have is low network latency. We use ClearCase and when we moved our source repository off of a hub in a room full of NT servers and out to the far side of a T3 in a different building, things got much faster. If the droids don't make you put your "server" in a "server room" with crappy network between you and there, it's not nearly as bad as it used to be. (Matter of fact, ClearCase with us in Chicagoland and the server in Akron wasn't as bad as having the server in the NT server room...)

Note that we don't use derived objects (DOs). But we don't have a full-time (or even part-time) ClearCase tuner; I'm not even 100% sure what there is that they'd need to spend all day tuning. The only thing we do beyond 100baseT and an otherwise decent piece of network is cp -R the source to a local disk so we can search for content (find |xargs grep, vs. label/branch/attribute searches) faster when the content hasn't changed recently.

I've heard the stories, but except for clearmake/derived objects I'm not quite sure what the fuss is nowadays.

cvs update by Sheepy · 2002-03-18 05:05 · Score: 1

Developers I work with are asked to do, at least, an update on each file they are about to edit. We almost never have conflicts with CVS.

Re:ClearCase? Leader building an SCM empire, maybe by crucini · 2002-03-24 10:13 · Score: 2

Interesting. At my current job we just dodged the ClearCase bullet by implementing CVS. Although there is companywide pressure to use ClearCaes, we met management's objectives with CVS. We sensed a bit of 'empire building' on the part of the ClearCase team, and were worried about adding a dependency and possible bottleneck to our small and self-contained team.

However, I still think that ClearCase is the leading source control system. Every big place where I've worked or contracted uses ClearCase for their primary software product. Leading product != lowest TCO. Windows and Oracle are examples. In fact it seems as if the more resource-intensive and troublesome an application is, the higher its visibility and prestige within the enterprise.

Slashdot Mirror

Tips on Managing Concurrent Development?

248 comments