> -----Original Message-----
> From: Marco Jansen [mailto:sartrix_at_gmail.com]
> Sent: Wednesday, July 07, 2010 4:44 PM
> To: dev_at_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.
Received on 2010-07-08 11:54:09 CEST