The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Source control -check-in practice

How do you handle such scenario(source control is subversion,one visual studio solution has 10 projects,and continuous integration server is setup) -Say,you have worked on 3 files,but they are in different projects.One developer in our team,checks in each file one at a time.The problem-CI builds fail(if other 2 files are required).I feel,one should check-in everything in one go.What is the best practice?
Sunday, January 27, 2008
One suggestion:

Have some kind of delay in the check-in builds, say it's 30 minutes.

Then the developer has 30 minutes to check in all the files, as in

10:31 check in proj001/a/b/mnop.c

10:34 check in proj002/d/e/ghi.c

10:39 check in proj003/x/y/

11:09 - thirty minutes has expired, build finally starts

That's better than launching multiple builds, as well.

This is also important when there are multiple developers.

The dark side of this is that the build can be indefinitely postponed if many people are checking in, so there is room for tweaking the parameters.
dot for this one
Sunday, January 27, 2008
I'd say that checkins should not break the build, but am having a hard time getting a clear picture of what is happening here.

How are these different projects if they have some interaction?

Why does checking in one file cause a build to fail?  Are the changes changing the API?
Sunday, January 27, 2008
If you can't check into the trunk without breaking the build, then create a branch to check in to, and then merge back into the trunk later.
Sunday, January 27, 2008
What's the problem with checking in all files at the same time.

Regardless if they belong to different "projects" as in MS Visual Studio Project or your IDE project, they all belong to THE project - as in business project, and they are all required to compile; IDE project files are just a way of organizing your source files.

At the end of the day, a broken CC means THE project is non-functional and you still have to check-in all files - either in one-go or multiple times.

PS. I fail to see who would insist multi-check-ins if you need all to compile.
Sunday, January 27, 2008
Your developer needs to get a better understanding of what kinds of changes break the build and what kinds don't.  This usually isn't that difficult, but it does take a bit of thinking about instead of reflexively checking files in.

You might also look at instructing your team about how to mark old interfaces with Obsolete, which can also help prevent intermediate broken builds.

Even where people are careful about it, everybody breaks the build once in a while.  But if it's happening all the time, then it sounds like your developers just haven't thought much about how the ACID properties of a database apply to source control.
Kyralessa Send private email
Sunday, January 27, 2008
> What's the problem with checking in all files at the same time.

Yes. Subversion has atomic commits, and that's how it has to be used in this kind of case.

Monday, January 28, 2008
Check ins should be atomic.

If you changed 3 files as part of the same piece of work, then they should be checked in together.

If the 3 files were part of 3 different tasks, why not check each of them in as soon as the task is completed and tested?
Monday, January 28, 2008
A bit off topic, but here it goes: how small should changes be and how often should they be checked in? I believe that the changes should be as small as possible and as someone pointed they should be complete (the project must remain consistent).

Also, do you think that this shouldn't apply for projects that have just started? I've heard someone saying that there's no point in using many small changes since the project is not finished at all (it's not even at alpha version) and because the other developers will be bugged too often (email alerts) about non-important changes, e.g. fixed typos, extracted method M.
Cristian Ciupitu Send private email
Tuesday, January 29, 2008
+1 on atomic checkins. They're a single unit, even if the actual changes are spread out over multiple files.
Chris Tavares Send private email
Tuesday, January 29, 2008
> What is the best practice?

You should have a build machine that does nothing but run a script ever half an hour, which gets all the latest code from source control and does a full build.

If the build fails it should turn the screen red for everyone to see and the person responsible for breaking the build is then responsible for fixing the build ASAP.
Jussi Jumppanen
Wednesday, January 30, 2008
FWIW...our CI server only kicks in if the Subversion repository has been untouched for 3 minutes.  Otherwise it backs off and tries again later.  Then it performs its checkout and starts its CI run.

If you couple this approach with atomic commits then only genuine screw-ups break the build.
MonkeySpank Send private email
Wednesday, February 13, 2008
Some automated build servers are so smart that this problem goes away.

For example, TeamCity from Jetbrains (find it with Google, I've got nothing to do with the company except that I am a satisfied customer).

It can be configured so that it tests your changes with Subversion in a pre-commit stage, and the changes are only committed if it doesn't break the build. Pretty amazing stuff.

It's free too for small teams.
Steve McLeod Send private email
Thursday, February 21, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz