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?"
Nothing beats getting together with team mates and toying with things in your spare time.
Past that, I suppose just add new people to the mix slowly.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
I assume you're the boss, so you could work 9am-5pm and he could work 5.30pm-1.30am.
That way you can still code naked.
Both excellent books for this situation, in my opinion.
Bogtha Bogtha Bogtha
The optimal programmer team size is 1.
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.
when i was taking a class on java programming our teach had us do the following and it was really helpful: the two people would come up with a design draft and then we would take turns where one person would type code while the other partner watched and scanned the code to catch any typos or bad code. we would switch off maybe every 20 minutes or so. this way no one person gets tired and burned out from typing or error checking. this process worked very well for me. it was very helpful to have someone there to catch any mistakes or make any on the fly suggestions they have that might make the programming better or more sleek.
Oh dear.
I don't know if you're aware of it, but you've just made an extraordinary claim.
Extraordinary claims require extraordinary evidence.
So let's hear it.
How we know is more important than what we know.
Sorry it's not about the perfect solution for your problem, but keeping
things in mind about the new context can improve things.
These are the lessons I learned from jobs and life either.
a.) be precise what you are talking about
- missunderstandings tend to poison the atmosphere at work
b.) clear missunderstandings as early as you can
c.) keep in mind that you now have a coworker
- trust him, he can do things on his own
d.) keep in touch with him
- this means you also report to him what you are doing
"primus inter pares" first within a group of similars,
you are the leader? dont behave like "the Führer"
e.) if you recognize anger, missunderstandings etc.. talk about
f.) keep in mind two programers are two human beings
g.) give him all the information you have
- if information is being held away, he would feel "pissed off".
h.)
- "smile"
- behave
- use "please" and "thankyou"
- commendation (wisely used)
g.)
let him bring some of his ideas in, discuss ideads,
if commendation comes from your boss, be modest and inform your boss if it was
your coworkers idea.
Communicate! The basic need for team work is comminication.
These are aspects I learned, when followed, it is allready team work, you don't need
a special conception for team work.
i agree w/ you about svn. we started 3 person team on svn under the assumption that it would be 'cvs but better'. after several disasterous merges we changed to hg. now we have 10 developers and everything is still working beautifully.
I don't know if you're aware of it, but you've just made an extraordinary claim.
I've also tried to point out that it was a personal opinion. Plenty have written about the SVN vs CVS debate, I'm just offering my opinion based on years of experience.
Google Code uses SVN.
Subversion wins, fatality.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
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
A couple of things -
1. I've had a lot of luck with git, as opposed to SVN. The ease with which it allows you to branch is a huge boon, and might save you some headaches as you work with other guys on your team. You might check it out.
2. I think the 37signals guys have a lot of good stuff to say on this in their book "Getting Real", which you can read for free on their web site(http://gettingreal.37signals.com/toc.php).
Mom?
By Hg do you mean Mercurial?
What is there about it that makes developers better or worse at merging?
I'm assuming that you're not agreeing that CVS would solve this particular problem, since it merges much like SVN does?
My Karma: ran over your Dogma
StrawberryFrog
Being a team begins with being on the same page, and can't be on the same page until you know each other. If you want to be a good coding team, you to get to know each other, hobbies, interests, favorite soda, etc. Geting to know HOW the other person thinks will reduce future problems that are usually the result of misunderstanding.
Bearded Dragon
If you want to hand over responsibility then you have to delegate trust. Do this in small parts to start with and reward anything that isn't awful, encourage where there's difficulty or dogma. Start with lots of small, well defined tasks. Don't be afraid to ask them for suggestions, advice and criticism - but again start with small matters. If you end up on the same wavelength then not only are you working efficiently, but you are not afraid to 'cooperatively go off at creative tangents' or sharing out some of 'that other stuff' ie the business tasks that pay the wages.
If you're not used to dealing with people then it might be worth while skimming a book that lists different personality types. (They all do it differently.) For example some people are good at detail, some good at starting, some bad at finishing - through losing interest and some bad at finishing because they must have absolute perfection. Being aware of these quirks will make you a better manager.
Finally, agree on standards such as file names and test procedures. Hunting through acres of baroque or haphazard code will be a miserable millstone.
Oh, whoops, someone just cut-and-paste details of their bank account into some code and committed without realising it.
"Administrator," you say, "can you please make that commit disappear completely out of the repository? I can't have anyone look through the history of that file and see my bank account details!"
Two scenarios: the first, the administrator uses CVS.. he types cvs admin -o 1.3 and revision 1.3 is gone! Phew! The second, the administrator uses SVN.. he says "uh, I'll get back to you on that in a few days.."
Because of this one point of difference I still don't believe SVN is a mature product.
In what world is it more complicated? It's less functional (from both a tool maturity and as a side effect of being LESS complicated), but I still dont understand your first "claim".
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
The original Pragmatic Programmer book is excellent I think.
http://pragprog.com/the-pragmatic-programmer
And since I also think an "agile" approach to managing software development projects is essential for most companies (certainly for any web-oriented development), I'm planning to check out their Practices of an Agile Developer book.
http://www.pragprog.com/titles/pad/practices-of-an-agile-developer
Jim
Think extreme programming and agile programming for programming constructs used in small to medium groups:
Of course, there's also different types of development models, such as object-oriented, aspect-oriented, et al. ad nauseum. Find a comfortable programming environment for your skill level (expression engine might be a good fit if you're a designer by nature), and keep it simple. Stay away from complicated constructs.
Also, read Joel on Software:
Get the book, he's a good, entertaining writer.
Here's what I'd suggest:
I hope that helps!
First, a disclaimer - My consulting company specializes in consulting on this topic, so you might consider me biased. On the other hand, I started this company because I had the experience, and saw the need.
Second, so this won't seem like a commercial, let me say I'm not answering this for any consulting opportunity... I answer slashdot questions all the time without looking for monetary gain; I'm just speaking from experience here.
There are a ton of great references for working together as a team - Any or the books from the Extreme Programming Explained series, a book on Scrum, Bob Martin's book on Agile Project Management, a dramatic reading of 'The Pragmatic Programmer', the book 'Practices of an Agile Developer' (in which several of my stories are published), or the book 'The Productive Programmer', recently published by OReilly (for which I wrote the forward), etc. But reading a book and putting it into practice are very different things. I strongly believe that teams should have mentors. (Thus the name of my company, CodeSherpas - as in we are guides to the terrain, but again, not a plug, just a reference for the kind of thing you need).
You have a fantastic opportunity here - to create a team culture where there are values like continual education, the team not afraid to learn from mistakes, peer reviews and retrospectives, iterative development, proper estimation techniques, and so on. Don't squander it. Find a good book that talks about the 'way things should be' - there are probably a zillion references here on slashdot already, but once you have that, make sure you get someone who has done it before... Even if it is just for a week of consulting/training, and then an occasional 'tune up'. And don't get a talking head... you want "visiting professor", not "ivory tower". A little bit of experience brought into your team now will mean that by this time next year, a group of ~3 awesome people who really know how to work as a team could be out-performing a team of ~7 people who just 'get it' enough to 'get by'.
-db
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
I run a small dev team for a company of 12 people. 2 of us are 'senior' dev guys, 1 is a graphics guy in marketing, and the 4th is a guy still in school. The rest are professional services or customer reps. My company does web crawling (lots of SQL, perl, automation) and then some web stuff to display the results and various reports. Pretty much I meet with the owner once a week and we make sure we are on the same page as to what the big projects we are working on (more news coverage, some cool new chart system, etc.) then we have a really quick tech huddle every morning at 9:00. Pretty much roll your chair over and we all look at the whiteboard, what did you do yesterday, what are we working on today. Are we on track to get X done for Monday? And y done for next Monday? Every piece of every project is on the board assigned to somebody. We use source control and have a ticket system, here's a good example of how we worked on a recent project together.
We needed to write a new mail system. We mail out a few thousand reports a day to clients but our old one was prone to errors and failures. I work mostly with SQL, perl, and architecture, I suck at web/interface stuff. I know enough about it to throw a table up but it is ugly. The other senior guy is great at interface stuff, slick javascripty boxes and he's OK with backend stuff but it's never optimized and will bog down. We know what each other is good at and we like it that way! So I sat down in a conference room with my senior guy and we mapped out how to do this. A queue system, this talks to this, we need a template here, this should be stored in a db, this should be in the code, etc. Broke it all down into pieces. I took on the details loading up of the queue system, the other guy took on the reading out of the queue to send the mails. With that he gave the graphics guy the task of "Write up all the CSS to make 4 templates of daily reports, make them look cool". He would then take that CSS and dump it into the mailing code he had written. I had our Jr. guy write internal reporting of the queuing system to track when mails go out and an internal dashboard of it.
Once it was decided what we were doing nobody had to waste time in meetings or anything, just needed to talk once in a while, "Hey, I'm going to put this flag in the queue tell you which template to use, how do you want to receive it on your end?" Each piece of the project is compartmentalized, I don't even need to think, "gee, I hope the graphics line up" or "Oh man, I'll need to write an internal report for this", it's all been delegated. I just do my part, everybody does there's and when it's all done we test and I just make sure the end product is solid. "Ok, reports going out now? I'll reboot the mail server, let's see if we lose any repots, the queue handles that right?" Not having to worry about all the details makes doing my part much easier. I worried about the details when we designed it, so now it's just getting it done. In the end I'm the director and it's up to me to make sure it's done but I act a lot more like a peer as I do as much work as the other guys, but I also handle all the meetings with the other groups. My team can focus on code and banging that project out while I deal with any BS that would just slow the team down. I've found this is a huge help on moral, how bad is it when the marketing guy wants his cake and eat it too and then the whole dev team just goes back to there desk and bitches about it. Instead I just go to the meeting 1 on 1 and will say, "I think you just wanted to cake here, no eating." That way he doesn't look silly and I can go back to my team and say, "Ok, we are baking a cake." and there is no confusion. I'd say half of being a good dev leader is understand wtf the people really want (not what they ask for) and then translating that to the rest of the dev guys, "Hey, let's be solution providers, not coders."
I've found using a ticket system is helpful for people outside my department for putting requests in, for
Modest doubt is called the beacon of the wise - William Shakespeare
Just because you don't know how to use doesn't make it immature. I've had to do this: not quite this scenario, but somebody dumped a couple of gigs of pdfs into a common repository that gets checked out into quota'd space. The dumpfile human readable format for svn is a joy, and the tools support filtering repositories according to paths for inclusion and exclusion. Rather than just killing revisions, you can do fine-grained edits over the entire history i.e all revisions intact but one particular file erased from the history.
Out of interest, you said originally that svn wasn't as functional as cvs. What do you think is missing?
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
svnadmin dump
(edit dump file)
svnadmin restore
A repository is a consistent history. If you want to change the history, you need reconstruct it.
I've been working with CVS and SVN for ~a decade and have never needed to delete one revision. The closest I've had to come to this is extracting a new repository from a subset of an old one. "svnadmin dump" let me do this without any trouble.
What's the stop the admin from reading the confidential info just before doing cvs admin, anyways?
æeee!
Priorities, as in "that's very far down on most people's list of priorities".
That's fine. To me the ability to back out a bad commit is one of the highest priorities. I like a clean repository. An essential feature I've had to use, on occasion, throughout my development years.
Plus I'm very fond of RCS style diff tracking. Understanding the storage back-end is most helpful.
People have different approaches to version control. Some see it as a means of easily tracking code changes. Others see it as a managed temporary storage area and are not too concerned with the cleanliness of the history. They are valid views although I have formed my own over the course of time.
The first thing to strive for, I think, is ensuring that code on which two people work still has structural consistency. Programming can be very personal, and aside from emotional aspects such as indentation and formatting, individual programmers sometimes have very individual approaches to problems. Chaos can ensue if, for example, two people on the same project have very different approaches towards exception handling.
One way to ensure consistency is to regularly review each other's code, at least initially. Discuss solutions that are clearly different, and agree on the best one. Alternatively you can buy a book that describes a good standard approach and a set of accepted design patterns for the technology that you use, and agree that you will both stick to that. For some platforms there are also software tools to enforce basic rules.
Now is also the time, if you haven't already done so, to put some effort in design documentation, as opposed to code documentation. What is the architecture of your system, and why? What are the underlying concepts, what design choices did your already make? What is the general principle according to which your code is organized? Those issues tend to matter little as long as you work alone, because you just keep them in your head, but that changes in a team. There you have to make them visible in some way, so that all people can work from the same baseline concepts.
Another thing that should be carefully managed from the start are internal and external dependencies. Many programmers have their own favourite libraries and technologies which they like to use for specific purposes, and they may even be emotionally attached to them, but in a team effort somebody needs to manage the dependencies. You need to keep track of the impact of changes, and prevent the frivolous introduction of additional external dependencies.
Well, anyday now I guess I'm going to move up from RCS.
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.
Wow, that's a pretty contrived example, don't you think? Honestly, someone doing something that galactically stupid should have their account info left there... anyone else who would find that information and used it would almost certainly use those resources better than a person that blatantly idiotic. And what if your CVS repository is on a file system that supports snapshots? What if it's been backed up in the meantime? What if someone else has already checked that code out before it gets deleted? Suddenly, it doesn't matter what code control system you're using... that data has been propagated and scrubbing it from everywhere is well-nigh impossible.
Your bank account details were commited??? WTF??? Sure they're also in some hacker hard disk since a long time ago!
Ok, somebody commited on CVS a directory with a confusing name (happens frecuently!), what's the CVS command to rename it? ...mmm... force everyone to commit, do a full copy and delete, and force everyone to checkout again? of course this is "mature" in a sense of "obsolete".
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.
a single svn move (Rename) from the middle of a directory tree can corrupt an svndump so that svn wont import it. use svnsync now.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
You don't optimise for incredibly rare situations.
What proportion of your time is spent reversing in your car? Of all the miles/kilometres you travel, what percentage?
Is there value in having a reverse gear on a car? One could argue "no" as it is only infrequently used. How about fog lights? Even less frequently used (depending on where you live). Anyone carry a spare tyre in their car? I've personally never needed a spare tyre in all the years I've been driving, yet I still carry one. I've taken the wheel off once, so having the jack has proved useful. There's a fine line between rare and never.
At the company I used to work for there were about 5 developers and we used Microsoft Visual SourceSafe, which didn't actually seem to be that safe. The main nightmare was when we needed to have several versions on the go, e.g. one release version that was just for bug fixes etc and another version that was for development. It was annoying because bug fixes in the release version had to be copied over to the development version (and sometimes vice versa). There are obviously better ways to do things and we were quite conscious that this kind of source code management was our dumbest area.
One day we were at a conference with our competitors and we were sure they were smarter and more professional than us, so after a few drinks we started talking about the nightmare of managing source code. I said "How do you deal with managing the code and versioning etc, do you use sourcesafe or something better". To which he responded "Oh, I just keep my source code on my machine and he keeps his on his laptop." These were the two directors of the company, and obviously the developers as well!
1. Keep the team small. 2-4 people is best.
2. Ignore heavyweight Methodologies and Methodists.
3. You need a specification, a small document in the language of the customer, that describes what the customer hopes to accomplish with the software you're writing. If the customer cannot understand the spec, you're doing it wrong.
4. You need some white boards.
5. You need to get good with a pretty-printer so you don't have to waste hundreds of hours arguing about coding styles.
6. If you have documents that describe the programs and they are constantly getting out of sync with the code, write clear code with decent names and throw the documents away. On 99% of the projects I've seen (mostly Fortune 500 co's), the documentation outside the code quickly becomes actually misleading and slows people down if they read it first in their attempt to understand the code.
7. 1 talented, motivated, socially adept programmer is worth 1,000 mid-range unmotivated socially inept programmers.
Peopleware is pretty good. Mythical Man Month is better.
Good luck.
maybe you should have read svn book first, eh?
- Arwen, I'm your father, Agent Smith.
- Well, you're just Smith, but my father is Aerosmith!
How about the backing storage? If shit happens, I'd rather try to recover from text files than binary chunks
Do you even lift?
These aren't the 'roids you're looking for.
Well, that certainly is an opinion you have there. The ability to absolutely remove a revision from a source control repository is not really a positive. If a revision can be conveniently deleted, that means no truths can be gleaned from a code audit.
You can accidentally paste your bank account number on a discussion forum, and there is no technology to make people unremember it. Guess you shouldn't use Slashdot anymore then, huh?
To: coders@example.com
Subject: Working on main.c, leave it the frig alone until further notice. EOM.
Problem solved :D
How are sites slashdotted when nobody reads TFAs?
Whenever I have a project at work or at home, I expect some basic things.
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.
2. Communication channels. Email addresses of everyone. A group email that goes out to all teammembers is helpful. IM of everyone - Trillian, GAIM, I don't care.
3. Version control. SVN for me.
4. Project/Task/Issue/Bug tracking. I use SVN integrated with Trac at home. It's not very good compared to commercial offerings, but it works.
5. Standardized build and deployment. ANT/Bash scripts/whatever
6. Basic development practices (test/commit often), QA methodology/granularity. The more experience you have, the better you get at this.
I like to have 2-4 deployments. Production, QA - daily build via cron, Dev - build of latest commit via svn hook, and LocalDev - complete build on each developer's machine(s) pre-commit. When QA+Product Owner(s) sign off, move from QA to production as a release. This is "best case" and often you have to compromise based on necessity or need. This means up to 4 different builds and deployments, although QA and Production should be near-identical.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
yeah.. mods on crack.. please do use svn and cvs in real projects before modding me troll, idiots
- Arwen, I'm your father, Agent Smith.
- Well, you're just Smith, but my father is Aerosmith!
The first thing I'd recommend is to get the Software Project Survival Guide. It doesn't apply to all projects, of course, but it's an invaluable guide and source of best practices for team-based software development.
http://www.stevemcconnell.com/sg.htm
The second thing, of course, is to actually read it. (I'm still working on that part myself.)
g.) give him all the information you have
In general I would agree with that advice - it's no fun [and certainly not productivity enhancing] to be in an environment where people are playing games and keeping secrets from one another.
The big exception I would make, however, is if you get even a whiff of the remotest possibility that your job might be under the magnifying glass as far as elimination is concerned.
If existing employee dude is in his late 40's, pulling down $150,000 a year, and if his healthcare costs are about to leap into the stratosphere as he enters his 50's, and if brand-spanking new employee dude is in his early 20's, and willing to work for a fraction of that [say $50,000], with almost no healthcare costs whatsoever, and if existing employee dude senses that there really isn't enough excess work lying around to justify the new hire, and if he suspects that the suits might be grooming brand-spanking new employee dude as his successor, then it might be time for existing employee dude to become a little less helpful to people, and a little more indispensable to them instead - if for no other reason than to buy a little time to figure out a game plan for what to do after his position is eliminated.
There is an even finer line between good and bad analogies.
Communication (sit together), frequent deployment, test-driven development, frequent feedback from users... does that sound like a good plan? If so then I highly recommend "The Art of Agile Development" by James Shore and Shane Warden.
Except that he didn't say "You don't optimize for situations that take small amounts of time." He said "You don't optimise for incredibly rare situations."
This is more like, for instance, lowering the top of a convertible: It's done, but it's such a small part of operating the car that it doesn't matter that it's slow. Except since this is a rather low-importance (In terms of the program's purpose: to the programmer with the bank account, of course it matters a great deal) operation that will occur only rarely, it doesn't matter as much as, say, atomic commits, which is directly tied to the core function of the software, and potentially affects every single commit.
To speak directly to your analogy, although I only drive my car in reverse 5% of the time (Arbitrary small number), I use reverse drive every time I exit a parking lot, or twice per drive. If reverse drive didn't work, my car would not be functionally parkable except in the rare case where I could drive through in forward. In your additional examples: Yes, you have fog lights, a spare tire, a jack. And these are indeed important. But does changing a tire need to be as easy as reversing a car? No. It just needs to be possible, which it is in both CVS and SVN (Reference comments above for proof).
I read this in grad school. An excellent treatment on group dynamics and building effective teams. While it's geared toward software development, the concepts are applicable to many fields...
You are ugly and stupid,
Love from Linus
http://www.youtube.com/watch?v=4XpnKHJAok8
I drink to make other people interesting!
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.
A reverse gear is very often used, and thus the mechanics to use said gear is very convenient and easy.
Many people here would argue that SVN is easy to drive on a daily basis.
Changing a tyre is considered a very rare occurrence. The mechanics for changing a tyre are relatively difficult and time consuming compared to driving in reverse.
Here your argument appeared to be that an important feature of CVS is being able to change a tyre (delete a revision) with the flick of a switch.
If your roads are made of nails this is an excellent feature to have.
To debunk your bad analogy
What proportion of your time is spent reversing in your car? Of all the miles/kilometres you travel, what percentage?
I reverse at least twice a day: out of the driveway and into the road on the way to work. And then after work out of the car park and onto the road. Interesting. It's only a small percentage of distance but it is still a daily thing.
How about fog lights?
Less value, and I experience 'frequent' fog (about once a fortnight during winter) and I don't have fog lights. Why lug around the extra weight when you can either stop driving during fog or drive extra carefully with the regular lights.
Anyone carry a spare tyre in their car?
You'll find that it's mandated by law. I have used the spare several times in my many years of driving. In fact, without it I would have been stuck in the middle of nowhere at least twice at around midnight. Tyres are fragile things and are quite easy to blow out - hence the reason for the spare.
It's very easy to not be fragile with your source code. Be mindful of what you commit to the repository. '$SCM diff' before you commit is an excellent way to verify that you're not committing something that is totally stupid (your codes to arm all the nuclear weapons in the world, for example).
Aren't you reviewing your changes before you commit them anyway? I would have thought that with SVN/CVS where branching/merging are a PITA that you'd be working on trunk most of the time so changes would require proper review before they were committed anyway.
I drink to make other people interesting!
You just have do draw a line somewhere. I for one always have some garlic, a crucifix and a wooden stake in the glove compartment, even though it's quite possible I'll never need them.
You don't and I'm not gonna hold it against you. I'm not even going to say your car isn't properly equipped.
I don't know whether you were speaking from experience or just making a general comment, but have you tried looking into Mercurial as an alternative? It's a distributed SCMS, meaning everybody commits to their own copy of the repository and then pushes those commits to a central repository (if you go with a CVS/SVN-like centralized setup). The Mercurial interface is designed to work more or less like CVS and Subversion, and it uses patchsets and repository-wide versioning like Subversion, but it has this nifty command called "rollback" that lets you undo your most recent commit, provided you haven't pushed the commit anywhere else yet. I switched a 200k-line project over from CVS recently--avoiding Subversion for exactly the reason you give--and it's worked fine for me so far; I even stopped mirroring my commits back to the old CVS repository because it was so much easier to roll back accidental commits in Mercurial. Being able to commit individual changes when I'm on the road without a net connection, rather than saving them all for when I get home and trying to separate out the changes afterward, is a nice bonus as well. (And I have to admit, I like how Mercurial names its "annotate" command "annotate" rather than Subversion's immature-sounding "blame", though admittedly not all the documentation is up to quite the same standard.)
That said, Mercurial's toolset isn't nearly as full-fledged as Subversion's. In particular, there doesn't seem to be an explicit equivalent to Subversion's dump/load process, so if you want to obliterate a commit other than the last one you're pretty much out of luck (though it might work to hg export everything but the problem patch and then hg import to an empty repository). You also have to deal with the fact that "revision numbers" are no longer constant except within a single copy of the repository, and you have to refer to hexadecimal node names if you want to talk about a specific patchset with anyone else. For my project, I treat the revision numbers of the central repository as canonical, and when building the project, I include the node name as part of the build ID when building from any other repository.
You may want to look at the docs at perforce.com. They have a lot of good ideas on tracking and such.
I found the biggest trick for a CM system, is in integrating changes from one line to the next. CVS sucks at this. I don't know about SVN. Perforce does okay, has some wrinkles, but overall, it's not to bad.
Linux had a real good Youtube video at google on Git. Similar ideas, different tool and a different way to handle the branches.
For reference, when I'm speeking of branches, I mean, Bod and Sally are working on adding 'Feature A' to a system (some set of programs) while Fred and Jack are fixing various bugs. There would be two or three branches where the people work. Once the changes are made, they need to be integrated together. If you have strong communications (namely you like each other) merging the changes together can be down right easy or at least no to horrific depending on the overlap of the changes. In any case, this is where a good SCM tool shines.
-- Many men would appreciate a woman's mind more if they could fondle it
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
SVN is more complicated than CVS, and less functional
Can I have some of what you are smoking?
Not that Subversion is the greatest VCS ever, but CVS is, in my opinion, a HUGE pain to use. The only reason to use it is for some sort of legacy system.
Pair programming? ;-)
I've lurked on their mailing list and I have to say I'm really impressed by the maturity of the group of developers that participate. What is really amazing is watching a new developer join and then be gently introduced into the culture of the list. That culture is polite, inclusive an respectful.
Most people soon learn the culture and participate, and the few that don't soon leave on their own accord. I think everyone who stays enjoys developing in that culture.
You may also be interested in this talk by a couple of the long-time contributers:
http://www.youtube.com/watch?v=ZSFDm3UYkeE
Put comments in your code! Don't be shy in the description of what you made/changed when you check in SVN. Include bug numbers. Provide accurate and detailed bug descriptions in your bug-tracking system, don't presume the others (or even yourself later) know what you have in mind.
Don't hide things you're not proud of: if you've made a stupid bug, well enter a new record in your bug-tracking system and then a honest check-in with the fix.....
Take the opportunity of being more than one to review each other code. Discuss.
Try to separate the tasks so that you don't have to work on the same source files at the same time. Don't keep the modified files for too long in your workspace, do frequent check-ins.
A good analysis will help making the project more modular and incidentally stronger.
btw: my own pair programming experiences were fruitful: motivating and funny, brainstorming was generating original ideas and of course many bugs were detected immediately...
Though I think this wouldn't be sustainable for a long project.
You're going to eventually anyway. It's slow, the model is seriously constraining, and it has a bunch of extra features that really aren't all that useful.
Consider using something like Mercurial (my favorite) or git instead. They are much better suited for collaborative development, especially if the teams are loosely coupled.
Need a Python, C++, Unix, Linux develop
Okay, CVS sucks. SVN sucks just a little less. (Yes, SVN still sucks.)
That said, I'm not sure that I can offer a better solution than either of those for all cases. Clear Case is far superior if you're into branching. SVN blows big hairy balls when it comes to branching, although it is still better than CVS, which really only has the single claim to fame of being better than Source Safe. That's like poking yourself in the eye repeatedly. CC sucks on administration though.
All the others I'm familiar fail in such unimportant areas such as atomic commits. I personally love it when my SCM tells me I've committed a piece of code, the logs agree, but the builds break because the actual code is missing - MKS/Starteam I'm specfically talking about you!.
Basically, SCM is much like CMS (Content Management Systems) they all suck, it's just a question of which one sucks less for your particular needs. Just don't be fooled that it's actually "good".
The cesspool just got a check and balance.
This actually comes up more often than you'd care to admit to. The fact that you can't delete a version, nor revert to a previous version in the tree and make it current are both reasons SVN fails miserably in the SCM world.
They're both minor though. Branching is SVN's major failure.
The cesspool just got a check and balance.
You have a very valid point.
This should be easier in SVN.
However, I have done it, and it doesn't take more than a couple of minutes.
It just requires some command-line fu.
We are Turing O-Machines. The Oracle is out there.
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.
Other than having some subversion, and maybe weekly meetings, I suggest that small teams should go as they go, and adding more procedure will only make things go slower.
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.
About blame:
svn help blame
blame (praise, annotate, ann) [...]
It's just an alias. If you want, you can praise! How is that for positive! Or ann, or annotate, if you're not into the brevity thing.
I'm aware of that, which is why I tacked that part on as a parenthetical comment. It wouldn't have a significant effect on my choice of SCMS, but if I did end up using Subversion, it would probably contribute a bit of extra stress from annoyance every time I happened across text (like "svn help") showing the "blame" command. (FWIW, Mercurial has the "blame" alias as well, but at least hides it from the "hg help" command list.) It's probably just me, but I prefer my tools to be neutral, direct and to the point, without extra cuteness.
I understand what you mean. I just know that I hardly ever use this command so it gets moved all the way back to the long storage part of the brain. Then, when I need to do an annotate, it's typically because I want to know who did that awful awful thing... so blame is exactly what I want to do (this sounds way more tightly wound than my real-life version, take with salt where needed) so that's what I remember. The alias to praise is being deliberately cute though.
Also, it may be that I miss one of the meanings of the word annotate, but is it even descriptive of the command?
Yes. And that's not optimization, it's a necessary feature. Optimization would be having seven reverse gears in your car to get optimal gas mileage in reverse.
None of these 'disadvantages' comes close to making up for the lack of atomic commits. Being able to commit some subset of your changes and break the build for everyone else dramatically reduces the usefulness of svn. The fact that there is a single version for the repository also reduces a lot of their other complaints. You need tags in CVS because you need to get a consistent snapshot of the whole tree. In svn, every commit creates a new tag, and you can make these easier to find by copying a specific version.
I am TheRaven on Soylent News
If there are only 2 of you, why don't you Pair Program? Run a Search on Xtreme Programming, I found it to be much more constructive. Maybe you guys can branch off back to coding as individuals after giving it a shot - or after you both feel you are almost at par Skill's wise and in terms of knowledge of what ever field you concentrate on.
How many times have you seen people write a little script to do something, and it includes their password ... and they commit it ... and then EVERYONE has their password.
People do stupid things all the time. Its a universal constant.
Optimization would be having seven reverse gears in your car to get optimal gas mileage in reverse.
Can't argue with Italian craftsmanship!
You don't have to be an XP zealot, but a lot of XP practices are very well suited to teams of 2-10 programmers.
Pair programming. I know everyone says they hate it, but a lot of people hate taking their medicine too... Fact is if you are working together on the same piece of code most of the time, you don't NEED a lot of other avenues of communication when you have a 2 person team.
My group develops fairly large and complex financial apps. Yet we maintain a small team and often have people from other organizations working on specific modules, so communication can sometimes be an issue. We've found that there are plenty of OSS apps that can be helpful to use, but the PROCESS has to drive application use, you can't build a good process around a tool.
To outline what we do. First of all I'm not a real big fan of coding standards. At least not the garden variety "you must format your source like XYZ" sort. In any case no one coder should "own" a particular piece of code, so if everyone works on each thing some of the time a "consensus style" will develop pretty quickly. In any case bad practices will get outed during code reviews pretty quickly and my feeling is that a couple rounds of "that's ugly and we don't want to do things that way" followed by a bit of refactoring which ends up with much nicer code will educate people a lot better than just a flat "you may not do XYZ", which doesn't really get into people's heads WHY they should do or not do certain things.
We do all our team communications via TWiki. All system documentation, javadocs, source jars, etc are there, as well as whatever amount of ancillary documentation any particular module or project needs. Its simple enough to use and there are plenty of plugins available for particular needs. If something can't be done directly in TWiki, then at least you can attach a file to a topic and that way people can get it and do what they need with it.
I'm not sure why you say SVN doesn't document team processes very well. The SVN book certainly gives you all the info you need to understand how to do specific things. Again we document revision control procedures on the wiki and there are some standard perl scripts to consistently do common operations (branch, tag, merge, etc) which makes it simple for coders to do these things. The SVN support in Eclipse is good too and generally the team features let you deal with whatever comes up.
Continuous integration is of course a great thing. Frankly I found most of the existing tools to be inflexible, overly complex, and hard to maintain. We have master build scripts written using our own build framework in perl. A simple cron job will do a master build and post the results to a section of the wiki, along with test results, dependency, test coverage analysis, etc.
95% of the work in my experience was just perfecting the process itself. Specific tools are secondary. As things became desirable or necessary to do, we just found a tool that would do that thing and made it fit in with our process. If it wasn't flexible enough, we went on to another one that was.
In the end we're pretty much just using Eclipse, SVN, TWiki, Cobertura, perl, and bugzilla.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
To annotate = to add notes to, so yes, it's a pretty accurate description (at least for Mercurial, where it prepends each line with the last revision in which that line was changed—I've never tried it in Subversion, so I'm not sure how it works there).
Oh, right. That does make sense. svn does the same.
I was thinking about how you can't see the commit message with blame/annotate, so that's the annotation you miss... But I get it now.
1. Use trac as a repo browser.
2. Set up CVSspam for receiving commit notifications via email. Upon receiving those emails, then you can take action if the code affected happens to belong to your area of expertise (or if you have ideas to implement the code better or if you spot mistakes, etc.)
trac is a life-saver when you're tracking down code changes.
Corporate Gadfly
Jonathan Archer: the most beaten up Enterprise captain in Star Trek history
I think the key to small development teams is a good mix of skills and a gelled, stable team.
"Best Practices" go in and out of vogue. Use the techniques that work well for you. Experiment with new things. This is a field still in its infancy- so be willing to spend time enriching yourselves.
Monitor your success in terms of code maintainability and developer/customer relations.
Do that, and you'll have the team you want.
-Ouija- poke 53280,11:poke 53281,12
do not become romantically involved with each other.
Star Trek transporters are just 3d printers.
Surely that's what you meant?
Tyranny isn't the worst enemy of a democracy. Cynicism is.
That is the worst video I have ever watched. At 12 minutes 55 seconds, when Linus says "Now, before I get started..." I had to just kill it there.
Take off every 'sig' !!
"Two scenarios: the first, the administrator uses CVS.. he types cvs admin -o 1.3 and revision 1.3 is gone! Phew! The second, the administrator uses SVN.. he says "uh, I'll get back to you on that in a few days..""
I can do that in about ten minutes... by hand; just seconds if scripted (I have done it so rarely I just didn't find the pressure to script it). On the other hand, it will take me about half an hour to do the same with CVS on a lucky day (sorry but no: it's not as simple as "cvs admin -o 1.3": that will delete a revision for *ONE* file. For the general case that you need to delete a whole revision made up of a bunch of files you will have to search *by hand* which files did got into that check in -and you will need to be careful: cvs ci not being atomic there's the chance for a different checkin to be intermingled with the one of your interest, look for their revisions and delete their history at such revisions one by one).
"Because of this one point of difference I still don't believe SVN is a mature product."
Because I don't know how to use the tool, I don't want to believe the tool is a mature product. Quite an intelligent argument.
"When using svn+ssh check-in method you have to play around with all sorts of group permissions and sticky flags"
Just don't use it. Use Apache/webdav instead.
On the other hand, when you use ext method with ssh on CVS (you are not using pserver except -maybe, for anonymous check outs, do you?) you end up with exactly the same gaming about group permissions and sticky flags so, again, I still don't see your point except that you don't know how to work with subversion (and you knowledge about CVS doesn't seem to be so deep either).
Yeah, that is certainly true... but passwords are relatively easily changed. He specifically said "details of their bank account". I am really hard pressed to imagine a scenario where I or anyone else would inadvertently C&P my bank account and routing number or a CC number into a source file, and then save it, and then commit it.
With multiple developers are you thinking in terms of code reuse/sharing? Or, are you basically compartmentalized in your own little development worlds?
If you work compartmentalized you run the risk of reinventing the wheel - that is, reimplementing what your partner(s) have already built.
Periodically you should get together with your team and talk about general purpose libraries that you have created, or see a need to create - and get everyone's buy-in on using, improving, and some standards around their location.
The APIs of your libraries should be very well documented - so your partners can use them easily for their parts of the project.
That being said, I am still trying to get my pardner to use the libraries I've created, and to put his own code for problems he has solved into it. To be successful you either need buy-in or the authority to set policy in this regard.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Yes, on your nickel. Good luck running a business that way.
If you want to stay in business, you need the cya paper, and preferably a contract stating how much additional changes to the project will cost ("lots" is a good starting point, to discourage never-ending projects).
Which was put into use first ?
From what I see, that whitepaper details Google hitting the limits of what Perforce can do.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
...because the dev team thinks of EVERYTHING!
I run a small dev team for a company of 12 people....
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
Even in that unlikely case, self-sealing (or even solid) tyres would be a better one.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Really? Like, everywhere in the world?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Really? Like, everywhere in the world
I wouldn't be surprised!
I drink to make other people interesting!