What's the best way to handle unfinished items in an agile sprint branch?

Question

If you work in an agile manner and have a branch for each sprint and also have policy that only finished and tested items can go back to the trunk, how do you best handle unfinished items?

Should the branch be kept alive and renamed into the new sprint branch and continue to work on these issues there? What if these issues should not be part of the upcoming sprint?

Update:

After answers from Alex Pereira among others I feel that I have miss-phrased my question, or rather misunderstood my own thoughts. I don't mean one branch per sprint. Rather one branch per release/feature set. And since that branch can continue to live the initial problem is actually non existent.

Combine that with feature branches and the issue with unfinished items becomes even easier to handle.

I do want to note that although developing towards the trunk (or any other predetermined branch) and then marking releases along the way is a feasable way that I have used before, I want a system that can scale from 1 to 100's of developers with minimal changes being needed. Thus there need to be ONE branch considered the stable one which done stuff goes into and there could be several parallel ones for different teams to work on features at the same time without interfering each other.

The ideas I had to facilitate all of this before I formulated like this

Answer 1

Not sure your setup is the most optimal here. I'm on a shop where we also do Agile, and we do not branch per Sprint, we rather branch it out per Release. I think it is unnecessary to have Sprint branches, when you could, in fact branch by Release and apply Labels if you wish for each Sprint. I also not not agree with the other comments where they suggest to let developers created their own branch, you are asking for a mess there.

In your case though, since you are already using that setup, I would say that you carry over the "hang over" to the next Sprint branch, and merge the current Sprint branch back to the Trunk. If the developers already started working on the current Sprint branch, then either move the code manually or do a baseless merge (if your source control allows it) to the next Sprint branch.

Update 4/17/2012 12:43PM:

We had a lot of discussions here at my job in regards to this. Basically, we have three agile teams working on three distinctive products, two .NET and one VB6 (legacy).

We wanted to figure out a standard way for all our teams to work on, and this is what we came up with - maybe it can help you:

Folder/Branching structure:

• Development (branched off main - will contain release branches for future development - aways updated by changes in Main - only merges into Main when is time for release and code passes initial acceptance testing)
  • Release 1
  • Release 2
• Main (this is the main trunk - contains relatively stable, release candidate code - where final builds are created)
• Release (branched off main when release approved by QA - never updated by changes is Main - Only gets updated by Service Packs to address critical defects or urgent enhancements, then changes are merged back into main)
  • Release 1
    • Service Pack 1
    • Service Pack 2
  • Release 2