Best Way to build a Release tag from cherry-picked revisions / changes

We are using Subversion to automate the release process for our web applications. Currently, we have a separate branch that represents a site in a deployable state; changes are merged from the development trunk into the branch, and the result is tagged as a release. After several months, I have come to the firm conclusion that merges are overkill for this situation, and they introduce significant overhead (both less and more after the upgrade to 1.6 - less since 1.6 seems to turn merges that essentially result in copies into copies, and more since merging multiple revisions often has to be done one at a time due to "duplicate" tree conflicts).

I am open to suggestion, but I think the best course of action is to create the Release tag as a series of copies and / or deletes; we're building a utility based around this that lets developers choose which of their revisions (and / or individual changes within a revision - not ideal, I know, but the flexibility is a requirement) should be applied onto a copy of the last Release to form the next Release. We encourage developers to check in frequently into the trunk (most of the changes are simple enough to not require a full branch, but they still may take a few days), so not every revision is necessarily one to be released, and we would like explicit confirmation from the developer that a change is ready for QA / Release.

Assuming that there is already an open Release (one that is copied from the last closed Release with or without changes), here are the steps I envision:

For Each Selected Change
  If It's a Delete
    Delete the matching target in the Release
  If It's an Add
    Copy from the source to the matching target in the Release
  If It's a Modify
    Delete the matching target in the Release
    Copy from the source to the matching target in the Release

We will investigate optimizations of the above once the base process is functional.

Questions:

1) Is there a better way to manage a Release that consists of cherry-picked changes?
  I will search for tales from the trenches, but any feedback would be fantastic.

2) What's the best way to perform the process above as an atomic transaction (i.e. a single Subversion revision)?
  Operations against the repository directly involve the least overhead (since all of the operations above are cheap operations), but that has the possibility of leaving the Release in a partial state if an error occurs mid process.

  Is there a good way to perform the above against a working copy without copying a bunch of unnecessary information? If I sparse check-out just the directory structure, I still end up with file copies (2x because of the copy cached by Subversion) for any of the adds and modifies; it's still better than checking out the whole Release (currently around 300 MB for a working copy). Is there any way to bundle the operations as an atomic change without copying any files or properties at all?

Thanks,

-- 
Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2374480
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].