Greetings, In the years I've been using SVN as a developer in a rather dynamic development team, we've found one 'gap' we consider in SVN. The intention of this mail is to figure out whether this first of all is indeed a gap, a known gap and perhaps even planned feature, or actually implemented but overlooked by us. Should the requested feature not be implemented nor planned yet, then I'm willing to consider working on it myself as a future contribution.
The issue we have is that we use trunk as a stable version, but with ongoing maintenance. Quick bug fixes to improve stability are generally directly committed to trunk, and sometimes even rapidly deployed from trunk. Extended changes, often longer-term projects, are supposed to go in branches. The biggest problem is that these branches do not automatically receive the maintenance and fixes committed to trunk. Ofcourse, there is a known work-around for this: Merging trunk into the branch; and this could even be automated with a script-hook. It still poses a problem that this merge is considered a change from the branch's viewpoint, and therefor gets committed on its own in a seperate revision in the branch once more, while all it is is an update from trunk. This often complicates the final merge from branch back to trunk, since the changes have been committed in both. So therefor, what we would like to see is to be able to have a transparent branch: One which fetches updates from both branch and trunk, without having them listed as changes or triggering commits. In essence it's reading from two branches, where a last known revision of a file could be from either branch, and committing to one only when it has changes from this 'either' latest revision. If it is a current feature, I'ld be happy to learn how. If it isn't, I'ld happy to dig in and contribute to make it possible. I'm looking forward to comments, Marco Jansen