> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_xbc.nu]
> Sent: Thursday, July 29, 2010 10:05 AM
> To: dev_at_subversion.apache.org
> Subject: Re: Suggestion: Transparent Branching
>
> On 07.07.2010 18:29, Greg Hudson wrote:
> > On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote:
> >
> >> 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.
> >>
> > I'm not sure if this is a feature of any popular version control system.
> > What would happen if trunk changes didn't merge easily with the changes
> > on one or more transparent branches?
> >
>
> ClearCase and AccuRev come to mind. AccuRev might not be that popular,
> but ClearCase definitely is.
>
Ahh, I think you refer to "Pass-through streams", where an individual file is branched and changes to that file occur on the branch, but changes to all other files occur on the trunk where the branch was initially created.
It’s a powerful idea (especially when you come to work with partial inclusion or exclusion filters) but requires a powerful view to keep track of what you're changing and a good system for keeping track of a branch's parent(s).
Eg. I have a directory structure like: /Framework and /Framework/Plugin. I branch the plugin directory so I can work on that, but I still see the full directory structure. If I make changes to anything in the Framework directory, it occurs on that branch that is shared by all. If I make a change in the Plugin directory, only I see the change until I merge it back.
I think it's possible SVN could manage this with a 'redirect' property that sends any commit/update operations to a specified revision. So you still branch as usual, but any operation on a directory would be made to apply to a directory elsewhere in the repo.
Received on 2010-07-29 19:36:39 CEST