[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Suggestion: Transparent Branching

From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Thu, 8 Jul 2010 10:53:25 +0100

> -----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
> maintenance. Quick bug fixes to improve stability are generally
> 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
> receive the maintenance and fixes committed to trunk. Ofcourse, there
is a
> known work-around for this: Merging trunk into the branch; and this
> even be automated with a script-hook. It still poses a problem that
> merge is considered a change from the branch's viewpoint, and therefor
> committed on its own in a seperate revision in the branch once more,
> all it is is an update from trunk. This often complicates the final
> from branch back to trunk, since the changes have been committed in
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
> branch: One which fetches updates from both branch and trunk, without
> them listed as changes or triggering commits. In essence it's reading
> two branches, where a last known revision of a file could be from
> branch, and committing to one only when it has changes from this
> 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

This is an archived mail posted to the Subversion Dev mailing list.