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
Received on 2010-07-07 18:06:36 CEST