Forbid developer to commit code because of making weekly build

Question

Our development team (about 40 developers) has a formal build every two weeks. We have a process that in the "build day", every developers are forbiden to commit code into SVN. I don't think this is a good idea because:

1. Build will take days (even weeks in bad time) to make and BVT.
2. People couldn't commit code as they will, they will not work.
3. People will commit all codes in a huge pack, so the common is hard to write.

I want know if your team has same policy, and if not how do you take this situation.

Thanks

Answer 1

Normally, a build is made from a labeled code.
If the label is defined (and do not move), every developer can commit as much as he/she wants: the build will go on from a fixed and defined set of code.

If fixes need to be make on that set of code being built, a branch can then be defined from that label, minor fixes can be made to achieve a correct build, before being merging back to the current development branch.

A "development effort" (like a build with its tweaks) should not ever block another development effort (the daily commits).

Answer 2

1. Pick a revision.
2. Check out the code from that revision.
3. Build.
4. ???
5. Profit.

Answer 3

Sounds frustrating. Is there a reason you guys are not doing Continuous Integration?

If that sounds too extreme for you, then definitely invest some time in learning how branching works in SVN. I think you could convince the team to either develop on branches and merge into trunk, or else commit the "formal build" to a particular tag/branch.

Answer 4

I have worked on projects with a similar policy. The reason we needed such a policy is that we were not using branches. If developers are allowed to create a branch, then they can make whatever commits they need to on that branch and not interrupt anyone else -- the policy becomes "don't merge to main" during the weekly-build period.

Another approach is to have the weekly-build split off onto a branch, so that regardless of what gets checked in (and possibly merged), the weekly build will not be affected.

Using labels, as VonC suggested, is also a good approach. However, you need to consider what happens when a labeled file needs a patch for the nightly build -- what if a developer has checked in a change to that file since it was labeled, and that developer's changes should not be included in the weekly build? In that case, you will need a branch anyway. But branching off a label can be a good approach too.

I have also worked on projects that make branches like crazy and it becomes a mess trying to figure out what's happening with any particular file. Changes may be committed to multiple branches in the same timeframe. Eventually the merge conflicts need to be resolved. This can be quite a headache. Regardless, my preference is to be able to use branches.

Answer 5

We create a branch for every ticket or new feature, even if the ticket is small (eg takes only 2 hours to fix).

At the end of each the coding part of each iteration we decide what tickets to include in the next release. We then merge those tickets into trunk and release software.

There are other steps within that process where testing is performed by another developer on each ticket branch before the ticket is merged to trunk.

Developers can always code by creating their own branch from trunk at any time. Note we are a small team with only 12 developers.

Answer 6

Both Kevin and VonC have well pointed out that the build should be made from a specific revision of the code and should not ever block the developers from committing in new code. If this is somehow a problem, then you should consider using another version management software which uses centralized AND local repositories. For example, in mercurial, there is a central repository just like in svn, but developers also have a local repository. This means that when a developer makes a commit, he only commits to his local repository and the changes will not be seen by other developers. Once he is ready to commit the code for other developers, then the developer just pushes the changes from his local repository to the centralized repository.

The advantage with this kind of an approach is that developers can commit smaller pieces of code, even if it would break a build, because the changes are only applied to the local repository. Once the changes are stable enough, they can be pushed to the centralized repository. This way a developer can have the advatange of source control even though the centralized repository would be down.

Oh, and you'll be looking at branches in a whole new way.

If you became interested in mercurial, check out this site: http://hginit.com

Answer 7

Step 1: svn copy /trunk/your/project/goes/here /temp/build

Step 2: Massage your sources in /temp/build

Step 3: Perform the build in /temp/build. If you encounter errors, fix them in /temp/build and build again

Step 4: If successful, svn move /temp/build /builds/product/buildnumber

This way, developers can check in whenever they want and are not disturbed by the daily/weekly/monthly/yearly build

Answer 8

Wow, thats an awful way to develop.

Last time I worked in a really large team we had about 100 devs in 3 time zones: USA, UK, India, so we could effectively have 24 hour development.

Each dev would check the build tree and work on what they had to work on. At the same time, there would be continuous builds happening. The build would make its copy from the submitted code and build it. Any failures would go back to the most recent submitter(s) for code for that build.

Result:

• Lots of builds, most of which compiled OK. These builds then started automatic smoke testing scenarios to find any unexpected bugs not found during testing priot to commiting.
• Build failures found early, fixed early.
• Bugs found early, fixed early.
• Developers only wait the minimum time to submit (they have to wait until any other dev that is submitting has finished submitting - this requirement made so that the build servers have a point at which they can grab the source tree for a new build).

Most devs had two machines so they could work on a second bug while running their tests on the other machine (the tests were very graphical and would cause all sorts of focus issues, so you really needed a different machine to do other work).

Highly productive, continuous development with no deadtime as in your scenario.

To be fair, I don't think I could work in place that you describe. It would be soul destroying to work in such an unproductive way.

Answer 9

I strongly believe that your organization would benefit from Continuous Integrations, where you build very often, perhaps for every checkin to your code base.