Couple of Q's related to working with teams

[GodlessAstronomer]

I'm studying computer science and as part of my Software Engineering class I'm currently working on a project with a team of 7 people, including myself. This is the first time working with a team, as opposed to working completely in isolation. It has presented some.... interesting challenges. There are some really smart people who don't give a damn about the project, some enthusiastic people who are not strong programmers, and one guy who quite obviously wishes he wasn't involved.

Anyway, the main reason I wanted to start this thread was to ask about Subversion checkins. How often should we be expecting to commit code? I've been using SVN for my own personal projects as glorified cloud storage for a while now. I generally check out the code, complete one feature or bug fix, test thoroughly then commit. Some people on my team are committing code literally every 2-4 minutes for a couple of hours a day. It's making it very difficult to follow the SVN history, find the correct diffs when a bug presents itself, etc.

Is this normal behaviour, or should I talk to my team about it? It seems to me that if you're submitting code that often then there's no way in hell that you're sure it's correct and as far as I'm concerned untested code doesn't belong in the repository. Am I being too anal? Thanks in advance, I am enjoying working in a team but the challenges involved have surprised me.

 

[chronodekar]

Originally posted by: GodlessAstronomer
There are some really smart people who don't give a damn about the project, some enthusiastic people who are not strong programmers, and one guy who quite obviously wishes he wasn't involved.

Looks like a typical team to me. (You'd be surprised how often this kind of bunch comes in 'professional' environments too...)

But more to the point, having limits of how many times you should check-in is pointless. At the same time, checking in every single line of change is an overkill.

Try talking to your team about a compromise. Tell them that the purpose of svn is to make it easy to go through code history. What is the benefit of it if every single line is checked in separately?

That said, personally, I like making extra check-ins myself. It gives me the feeling that I'm doing something. (whether I'm productive is another matter, entirely) So, to help the team, I just make a separate branch for myself. At worst, all I end up doing is increase the version numbers, but at least the team is not bothered by my quirks.

EDIT : You are not being too anal (whatever it means) by insisting that un-checked code NOT get committed. There are tools to let you check that, but I don't remember them just now. A friend of mine, who works in another company had a great admin. The guy made a Perl script that would verify that any code you check in would compile. If the compile failed, you wouldn't be able to commit it.

 

[degibson]

I make checkins whenever my deltas are coherent, compile cleanly, and pass all tests. If thats after a one-liner, I check it in. Sometimes it adds 30-40 files. It all depends.
For my part, I look at SVN history as a series of transactions on a codebase that takes it from a working state to a working state -- and the smallest possible set of deltas should constitute exactly one revision, for optimum unrolling later if need be.

 

[KB]

Checking in every 2-4 minutes is crazy. I can't imagine attempting to find the file to revert back to, say before a feature was implemented. For my group there should be one check-in per bug/feature request and the code should compile and work or it shouldn't be check-in. The exception to this is that at the end of the day a check-in should be performed even if not finished. Its is extremely rare (hasn't happened yet in my group) that someone has lost a few hours work because they waited to check-in and had a PC die on them.

 

[imported_Dhaval00]

Maybe I am speaking for myself, but I have observed this trend [of checking code in every few minutes] quite frequently. However, the major reason (at least in our environment) is that people hate losing work - many a times your IDE may crash, taking with it those 30 lines you added in the last 15 minutes, which fixed a bug. I guess the implicit logic is that your code repository has a more reliable storage back-end, and that it is backed quite frequently.

As far as tracking changes go, if you're in an enterprise environment, teams track changes based on release versions. Also, when you have multiple contractors (or even full timers) working on your project, you want them to check their code in, preferably, on a daily basis. I don't want to implement thousands on lines of code towards the end of a project in case you get hit by a bus, and you didn't check in your code because it wasn't in a "reliable" state.

Taking this a step further, you can have multiple repositories - one that can be used for frequent check-ins while another one which is explicitly used for release management. Again, this is what happens in larger teams - you have a developer's repository (which allows him or her to check in code whenever he or she pleases), who after working on the code releases the build to release or configuration management. They then make sure the build works and/or installs (places like Microsoft have multiple teams for each area) before pushing it over to the certification team. If the release gets passed, that is what gets put in production. At that point, from a corporate standpoint, you can be assured that your production systems have a code-base that was certified, not a code-base that was on a developer's machine, who left the company three months ago .

As a side note, it'd be interesting to see how other people here manage their releases/code-bases.

Edit: I personally don't have an issue with a team checking in their code every few minutes. However, the catch should be that in case they actually fixed a bug, they'd have better documented/commented the fix so you can search for it. the important thing is to set a standard that everyone can understand. This should all be part of the "coding standards" for your environment - something that every newcomer must read. Again, maybe I am overengineering this, but this is how [at least the teams I have seen in action] work. So yea, for your school project documenting the standards may be a stretch, but do follow them to save you some major headaches (especially if it is a senior project that spans multiple quarters/semesters).

 

[Markbnj]

Originally posted by: degibson
I make checkins whenever my deltas are coherent, compile cleanly, and pass all tests. If thats after a one-liner, I check it in. Sometimes it adds 30-40 files. It all depends.
For my part, I look at SVN history as a series of transactions on a codebase that takes it from a working state to a working state -- and the smallest possible set of deltas should constitute exactly one revision, for optimum unrolling later if need be.

This, although I know quite a few people who really use it as a remote storage system.

 

[troytime]

i only check in when my task (the reason i opened the file to begin with) is done and ready to be uploaded or worked on by another developer

 

[GodlessAstronomer]

Did anyone find it jarring going from university (where most work is individual) to a corporate environment (where you're working in teams)? I find myself becoming extremely suspicious of my team mates' code, even though there's no good reason to be. I'm always worried that they'll do something to break something I created or work outside of the spec. It's not that I'm underestimating my team - they know what they're doing (for the most part), but having worked on my own for so long has made me very... defensive(?) of my work. I suppose this is why they do this group project, to teach us how to work together. It's fun, but it also makes me nervous to know that my grade and the quality of the final product hinges not only on my work, but on the work of people I've only known a few weeks.

Do you enjoy working in a team environment in general? Any further advice with regards to working with other people (not just in the project, but in general) would be really great.

Maybe I just spend too much time at The Daily WTF to trust anything anyone else writes

 

[SearchMaster]

Every few minutes is crazy. We believe strongly in continuous integration, including unit testing every 30 minutes and hourly deployments to the test environment, but I would probably beat a developer if they created that many changesets. I'd say our average developer has 2-10 changesets per day.

 

[iCyborg]

Originally posted by: degibson
I make checkins whenever my deltas are coherent, compile cleanly, and pass all tests. If thats after a one-liner, I check it in. Sometimes it adds 30-40 files. It all depends.

Same here. Also, every check-in has to be approved by 2 other people. For 1-line bug-fixes, I may be able to commit a few of them in a day, but for features it is normally weeks, and sometimes months, though one would usually work in a private branch for a larger feature. We do nightly builds and run a large number of automated test cases every day (takes half a day to finish, and qa uses 20+ machines for that). Doing a check-in that breaks the build is baaad, because you've blocked auto-testing.
2-4 minutes would be completely unacceptable on the product I work on.

Originally posted by: GodlessAstronomer Did anyone find it jarring going from university (where most work is individual) to a corporate environment (where you're working in teams)? I find myself becoming extremely suspicious of my team mates' code, even though there's no good reason to be.

I had a course project with 4-people groups at univ, and it was a horrible experience for similar reasons as yours from the first post. Not until I started working did I start appreciating that working in a team can be fun, as everybody was very competent. There are good ones and better ones, of course, but bad ones don't tend to keep their job for long, especially these days when even good people are being laid off.

 

[zebano]

I only check in after I test my change and it works. That said, we have nightly builds based off of the latest and greatest checkins. If you break the build, you're buying donuts, so you better be sure that your code compiles and doesn't keep us from booting.

 

[SJP0tato]

Originally posted by: Markbnj

Originally posted by: degibson
I make checkins whenever my deltas are coherent, compile cleanly, and pass all tests. If thats after a one-liner, I check it in. Sometimes it adds 30-40 files. It all depends.
For my part, I look at SVN history as a series of transactions on a codebase that takes it from a working state to a working state -- and the smallest possible set of deltas should constitute exactly one revision, for optimum unrolling later if need be.

This, although I know quite a few people who really use it as a remote storage system.

Same here as well

Some people on my team only like to check in once a day or so. As long as it's not breaking anything I'm working on, and I don't need a component of the code they're working on sooner then it doesn't matter to me.

In general as common (odd because it can be uncommon) courtesy as often as you feel like it as long as you aren't ruining someone else's day by breaking what they're working on.

 

[GeekDrew]

Originally posted by: GodlessAstronomer
Maybe I just spend too much time at The Daily WTF to trust anything anyone else writes

I have the same sentiment, when working on my production network. Not that everyone is well-intentioned, but sometimes that doesn't cut it.

 

[tfinch2]

Anywhere from 1 per week to 5 a day. Depends on the magnitude of the change, where we're at in the development cycle, etc. I try to keep my changesets manageable so they are easier to review.