> -----Original Message----- > From: Marco Jansen [mailto:sart...@gmail.com] > Sent: Wednesday, July 07, 2010 4:44 PM > To: dev@subversion.apache.org > Subject: Suggestion: Transparent Branching > > Greetings, > > 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. > Surely you just want to merge only the revisions that were changed on the branch, not those that were merged from trunk. Doesn't mergeinfo help you here? If not, if you marked each revision that was merged, wouldn't that allow you to skip those when merging back to 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. > I do like the idea of 'automatic' merges to multiple destinations. So I would branch 2 times from trunk, then I could make a change to trunk and have that change cascade onto both branches (ie without performing 2 separate merges). That'd be pretty cool, though I don't know if it's possible or really desirable :) > 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. > Sounds like a bodge of a suggestion - you want a view of the repo where 2 branches are seen as 1, the latest revision from either is used? So if trunk was updated, it would suddenly take precedence and obscure the same file on the branch. That sounds like a good way to screw whatever it is you're working on, as your WC could change at any time - all those changes you made to branch suddenly disappeared and you see the file from trunk. Not good, and confusing as hell.