Suggestion: Transparent Branching

[Marco Jansen <sa...@gmail.com>]

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

RE: Suggestion: Transparent Branching

["Bolstridge, Andrew" <an...@intergraph.com>]

> -----Original Message-----
> From: Marco Jansen [mailto:sartrix@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.

Re: Suggestion: Transparent Branching

[Philipp Marek <ph...@linbit.com>]

Hello Marco,

On Wednesday 07 July 2010, 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.
FSVS (fsvs.tigris.org) is not a source control system per se, but more of a 
filesystem versioning system (like for /usr, /etc, or /).

But: FSVS allows to "overlay" multiple repository URLs, and the "topmost" 
entry is visible in the working copy.

See here for some more details:
http://doc.fsvs-software.org/doxygen-gif/group__howto__master__local.html

So the base checkout would be trunk, with an initially empty branch on top 
of that. As files get changed they get committed to the branch; updates from 
trunk would get through, though.


I'm afraid that this won't fit your bill completely, but if the project is 
big enough and the changes sparse enough so that no single file gets changed 
on both trunk and branch (or at least so infrequently that it could be 
merged manually) it might just work for you.

You're welcome to try it; the main site is http://fsvs.tigris.org, and some 
distributions already have packages available.


I'd be happy to hear about any feedback, ideas, and experiences; please 
share them on FSVS' users mailing list.


Regards,

Phil

RE: Suggestion: Transparent Branching

["Bolstridge, Andrew" <an...@intergraph.com>]

> -----Original Message-----
> From: Branko Čibej [mailto:brane@xbc.nu]
> Sent: Thursday, July 29, 2010 10:05 AM
> To: dev@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.

Re: Suggestion: Transparent Branching

[Branko Čibej <br...@xbc.nu>]

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.

-- Brane

Re: Suggestion: Transparent Branching

[Greg Hudson <gh...@MIT.EDU>]

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?