Slashdot Mirror
Stop Breaking the Build
Cap'n Grumpy writes "You know the score - you've just finished some coding, do a final cvs update before commiting, and all of a sudden all hell breaks loose. Your code now refuses to compile, or xunit starts flashing up red - test failures! One of the other members of your team has checked in something which breaks the build, and they just went out for lunch ... Argh! Did you know there is a solution to this problem? It is a system which makes it impossible for people to check in code which does not compile or test successfully. It allows coders to review others coding efforts code before it goes into the baseline, rather than after. It organises your checkins into logical change sets. It enforces continuous integration. It is linux based, and GPL'd. It's called Aegis."
Well, I think there is more work done on unix systems, and more programs are developed for unix systems than there is for windows systems.
The server side of computing is not really as narrow as you have explained it.
Another thing is, no, not everybody uses Windows, I do use it, but since we are here in slashdot, I'm telling you that most of the users around you use, and love, linux and apple systems, and use them as workstations as well (I have a linux work station although it's not my main pc too).
The idea that developing programs for windows is more important is wrong, I really don't like to spend my time developing a program to help Microsoft gain more power in the monopoly.
I am not much into software development for the time being, but if I get into that I'll always make sure to build programs for linux BEFORE Windows (or make portable solutions).
It's just that Unix is a nice OS for MANY things, not some things!
"What you 'seek' is what you get!"
"for closed source development you should rarely need to edit the same file unless your team is poorly organized or system poorly designed"
Oh, come on. That's such a load. I'll agree that CVS is a big part of the problem, but not because you shouldn't let more than one developer edit the same file at the same time. Rather, simply because CVS sucks.
I hate to admit it, because I love the open source movement, and I know what an important role CVS plays in it, but CVS relly does bite compared to some of the commercial alternatives. I mean, no trackable atomic changes? No means for integration with job tracking? A shitty-beyond-belief branch methodology? Poor tracking of and integration of changes across branches? Crappy permissioning structure?
Where I work we use Perforce, which I absolutely adore. Does not have any of the issues I listed above, works in unix and windows, is command line easy and has a pretty damn good GUI (compare to WinCVS, ack!), is wonderfully scriptable, and is really not that expensive (although I can definitely understand the desire to spend $0).
Anyway, you can't really expect to have a large group of developers both iterating and maintaining a fairly large codebase without ever needing to edit overlapping files... not unless you keep each function/subroutine/method in its own file. Even then, I imagine you'd still run into occasional change resolution issues. The better way to deal with the problem is not to close your eyes and put your hands over your ears; it's to outfit yourself with decent tools capable of dealing with real life. I know that with perforce, and I would imagine with most other half-decent source management systems, simultaneous edits are really not that big of a deal. Unless you've actually edited the same lines in the same file, the user doesn't typicaly have to do a damn thing. And regardless, it is still the fault of the first user to check in a busted file. Again, atomic changes mean that if it compiled for you, and you check it in, then compiles for everyone else.
:Wq
Not an editor command: Wq
Yeah, but what if your build takes over an hour? (Like where I work) Say you need something checked in, like now. You're sure it works, but you have to hang out for an hour to make sure it went in? There is a certain level of trust you need in a development environment. Waiting for it to completely rebuild simply isn't always an option.
Sure, you can generally do partial builds. But what happens when you just had to change that include file that somehow effects nearly everything else? You're stuck for that hour.
Yes, you're blocked from checking stuff in until the test build finishes, but even though you are SURE it works it's better to have a sanity check just in case.
Have some coffee, fill out the TPS report, look at pending bugs. There's a few things you could be doing during that hour.
I have been pwned because my
Having multiple developers tinkering with the same part of the same file is a project management problem- not a tool problem.
Well, as odd as this might sound, when anybody checks anything to our source control that breaks the build, they have to go out and buy the entire development team a coffee and/or chocolate cookies. This worked like a charm. It not only raises awareness and makes people more careful, it has actually increased moral in the team as we look forward to the weekly build to see who has cocked it up :-)
Never, ever lose a file again. Ever.
...or if you happen to have a high level of code reuse; or if you have doing firmware, software and driver development in parallel; or if you have a small but busy team; or if you have a large but busy team; or ... or ... or.
This is a ridiculous statement. There are any number of reasons that multiple developers will work on a single file at once, especially in a well structure organisation or development. Development, code inspection, fixes in response to testing and maintenance fixes (bringing a patch from a release into current) can ALL happen simultaneously in a development tree, and can ALL happen simultaneously in one file. They just shouldn't often happen simultaneously in one method/function.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
While I agree on most things, WinCVS is certainly NOT the GUI you should be comparing to - TortoiseCVS is.
I have used SourceSafe, Perforce (very lightly), WinCVS, and Tortoise. Tortoise is above and beyond the rest. I still use the command line sometimes for intricate log grepping, but for everyday usage, Tortoise is simply amazing.
TortoiseCVS