Slashdot Mirror
Guide For Small Team Programming?
dm writes "I run a small design shop and have been doing more and more web development, including fairly involved back-end programming of what's now essentially become our own CMS. Up to now I've been doing all the programming myself. Now we are working with a second programmer for the first time. I already use version control (SVN) and an issue-tracking system, and I guess we are both decent at what we do — although self-taught, but we both lack experience programming in a team context. Is there a useful guide for this? Most of the tutorials I have seen for Subversion are surprisingly organized from a single coder's perspective. Where else should I look?"
There are lots of things I could throw out, sure, but most of them came from principle numero uno - talk to each other. Learn each other's strengths and weaknesses, learn how each other works, learn when a process isn't working for one of you, and learn to evaluate each other's code. Process is really about leveraging communication to improve the product. So start building that communication.
For any enhancements you wish/are asked to make, break up the work into smaller sub-tasks and document these tasks somewhere. Then just have a free-for-all on the available work. Mark tasks as "in progress" and "done".
If you want to learn from/about each other, review each other's work. If you want to live dangerously, don't.
The best part of having a team is that you'll have multiple opinions on how to do something.
The worst part of having a team is that you'll have multiple opinions on how to do something.
For the love of Dog, please don't move from SVN to CVS.
SVN was designed as a "compelling replacement" for CVS. And it succeeds.
I've yet to see a compelling reason to move to SVN.
That doesn't mean that there's a reason to move back. If you don't see the benefits of atomic commits, keeping version history over file moves an renames, and rapid branching then by all means, stay with your CVS. Just don't drag other people back down with you.
If nothing else, CVS is pretty much a dead end. The next version of CVS is SVN. SVN has a development roadmap, CVS has migration-to-svn utilities.
My Karma: ran over your Dogma
StrawberryFrog
With the exception of that last sentence, that sounds like something I would tell someone to get out of doing any actual work.
Pairing does sound like taking it easy at first, but I suggest reading the whole Wikipedia article before saying that.
My Karma: ran over your Dogma
StrawberryFrog
Here's what I'd suggest:
I hope that helps!
Because of this one point of difference I still don't believe SVN is a mature product.
I don't think it's because the SVN team are incompetent or haven't finished the basic feature set yet and their product is "immature".
It's about priorities - Oddly enough, the SVN developer team and community don't seem to have prioritised the feature of a revision-tracking system totally losing track of a revision. Priorities, as in "that's very far down on most people's list of priorities".
My Karma: ran over your Dogma
StrawberryFrog
There's svndumpfilter - it can completely obliterate selected files. A complete dump/load cycle requires a bit of time, though.
See: http://subversion.tigris.org/issues/show_bug.cgi?id=516
Frankly, that's a pretty stupid reason to chose CVS over SVN.
To borrow from a concurrent thread, your comparison*
http://www.pushok.com/soft_svn_vscvs.php
As a matter of fact, you can use any db you like if you have experience with databases and SVN. This doesn't really speak to the weakness that you are trying to describe. Transparency of data storage. This is only accurate insofar as you would say that the average SVN user thinks there is no transparency in data storage of CVS. A lack of understanding often causes a user to claim something that isn't true. The entire history of SVN commit diffs is accessible through svndump. However, this has a LEGITIMATE weakness. svn move is a problem as svn can no longer reliably import dumps that have had an svn move executed (any # of times) in the history. Some of SVN's binaries are simply immature and do not work together seamlessly. For a substitute to svndump, see svnsync.
See *
How many digits are your tags? 5.10? This is not an argument. See *
*A number of assertions that are just opinion based on SVN isn't like CVS.
Other people have problems with CVS that aren't in that list like
--CVS lacks directory versioning. It keeps track of only files, not directories.
--CVS has weak support for the copy, rename, and delete operations on files, a result of the lack of directory versioning. (similar to svn!)
--CVS lacks atomic commits
From your years of "CVS" experience, you might have run into these (I did when I used CVS)
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Oh, whoops, someone just cut-and-paste details of their bank account into some code and committed without realising it.
Hands up everybody this has happened to.
Exactly. You don't optimise for incredibly rare situations. Especially when doing so means you can't have features that would be used each and every day.
Only if you're some freaky self-motivated person.
Otherwise you'll surf the web all day after getting up at 1pm and watching Daytime TV for a few hours.
Two people will motivate each other. Three people might even get the time to do other business essential things, like the accounts! Also nicer for pub lunches, two people is a bit one-on-one.
More than three and I think that you start getting communications issues, unless you are all working on very different projects rather than the same codebase. Once you're in the meeting room, with the projector, and the Wii, you'll end up playing Mario Kart, which kills productivity. Also there's enough people to not have the focus on your own work, so you'll surf the web unless you're self-motivated enough or have a deadline.
Productivity/person ration in a one man team is 0.4.
You are correct that a text-storage would make recovery easier, although I have doubts that it's at all possible to recover from the Berkley DB in most cases. My question is what kind of failure partially damages a repository that you want to recover whatever part of it you can? I assume a hardware failure. SVN stores text files, binary files, directories. A text recovery for these things would never really be possible anyways. The only way to recover such data would be from a backup regardless of the version control method. SVN is backed up by simply zipping the directory and putting a copy somewhere. I do this daily & weekly. This is how recovery is usually done which is indifferent to filetype. This same approach is done with CVS but causes some serious issues when trying to get everyone back on a restored copy.
Why would we want granular access to text files in storage? If 'recovery' is high enough on the list to warrant "the primary reason", your revision control needs to have access to the backend storage, the system must have a high failure rate and I would tag it unreliable. I don't know of a reason to want access to the backend storage directly. If SVN were somehow aberrant in this regard, I would admit it, but there are lots of utilities that do not have flatfile backends and it only seems to be an issue with revision control. Sourcesafe, GIT/Bazaar with its hashed key/values or god forbid its crypto hashes, means you can't access their files directly either. Is it really assumed to be a good thing?
I believe the point of version control is to track all changes, regardless of intent (bad commits count). This does not speak to anything else including recoverability method. I find it mildly disturbing that you can or would alter the history in CVS. In SVN you basically have to dump the entire repository history to make a change to the history. The number of times I've had to restore an SVN backup is 1. That was to do a test of the integrity of the zipped repository over the last 3 years, 12 repositories and near 10000 commits. SVN is stable enough for me.
In the case where you want or need the peace of mind to be able to alter the "backend storage", I hope you have a long and prosperous career with CVS. We just have different goals.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
1. Standardized IDE. Everyone use the same thing and you will be able to do builds, deployments, and fix bugs quicker. Eclipse/Zend/VC++ whatever.
That is the dumbest thing I have ever heard. Horses for courses. I was an Emacs guy until recently when I switched to Vim. We have a couple of other Vim people and an Eclipse guy here. Everyone gets by using whatever 'IDE' that they want. The IDE does nothing except provide them an editor. Forcing the same IDE on everyone is asking for reduced productivity.
Standardized build and deployment. ANT/Bash scripts/whatever
With this you don't need an IDE preference. We have Makefiles and Ruby scripts that do everything we need. SCM actions are mangled into scripts so branching, merging, etc are all handled and the right comments (according to our policy) are inserted into the repository. Releasing to production and staging servers is handled and everything works neatly.
If you get this part right you won't have the headache of forcing a GUI guy to edit code on the console and you won't have the loss of productivity when you get a console guy to try and use a graphical (read: crap) IDE.
I drink to make other people interesting!
If that is what you are after use git.
In general changing history is bad as it messes up
everyone who is working on that history. However
if you have to it is trivial in git to create a new branch without the bad commit and go from there.
That also matches the core simplicity argument. At it's base git is very simple, and easy to use,
and you don't even need to go to an administrator
to do all of these things, just to the guy who has
access to whos repository the changes are in.
Eric
I hear you on #6. I do enjoy automated documentation (like class diagram generators, API documentation tools, etc), but stuff that is done manually gets...ugh...fast...
Having a Wiki for the big stuff is a good idea, but beyond that? I'm currently working on some very very small apps (a lot of them, on a 2-3 weeks cycle per app), and when the QA or the customer points out a change request, I get scared to death.
Not because of the change itself... development tools have grown over the years, and even a significant change doesn't take me much time at all... But the documentation...oh god the documentation...
First you have to update the class diagrams and stick them somewhere on the network, then update the API doc (ok, those 2 are automated), then update the design document, then get it approved (I code during that time even though I'm not supposed to...if it gets rejected, I'll just roll it back, ugh...), then update the SRS because the analyst is too busy, get that approved too, then update the model diagram, then the screen prototypes, then....
Seriously, adding one textbox on a form requires the update of about 10 documents, approval of 2, syncing some with the others, THEN changing the code... The overhead is just crazy.
I feel a few automated tools (in the build system if possible), and a good Wiki is all you should need. If you need more than that (for the customer themselves for example), you hire technical writers who go back after the fact and document it...else you just get lost in the paperwork.
I hate seeing Agile hype mentioned. I've been programming for 20 years, and the biggest changes any company can see by embracing Agile development or more so with extreme programming, is convincing good programmers to leave or demanding raises to put up with all the BS.
I've been using Agile and Extreme methods for much longer than they had names, but misapplication of the techniques or thinking they're silver bullets to use in ALL situations will hurt your company.
That's the hard way dude.
svnadmin dump -r 0:500
(asumming 501 is the bad and last revision)
We are Turing O-Machines. The Oracle is out there.
I've also read that article. It's written by someone who hasn't worked with SVN yet. From that standpoint, CVS will compare favorably.
From any other standpoint, not so much. I have experience (actual, hands on experience, not "I read it on the web" experience) administrating and using both systems. SVN wins hands down. It is more robust, it's more user friendly (no more CVS login), it has functions that CVS lacks (svn move).
SVN's creators wanted to make the next, better CVS. They succeeded. If he's already using SVN, downgrading is a bad move.
If there's evidence the IDE is "shitty",
What you think is shitty and what I think is shitty are two different things.
There is no "my IDE" nor is there a place for personal preference over productivity
That's a very power-freak way of doing things. If you enforce rules like that then you're asking for trouble. I've worked in a few places now and I can tell you that the places that enforce those kind of rules almost never get very far.
In fact, the second-last job I was at was haemorrhaging people for exactly that reason. They went from 40 devs to 10 in the space of 12 months and couldn't find decent replacements because word got around that they sucked.
As I say, there's ways of standardising the environment without forcing everyone to use tools that they don't like day in, day out.
I drink to make other people interesting!