RE: feature request: dynamic branches (streams)

Thanks, I need to understand much more about subversion internal concepts before I can contribute much more; and as Ben pointed out earlier, the first step would be defining the concept of 'branch'.

I have however put more thought into Git & Mercurial vs AccuRev and how those concepts relate with Subversion. In my mind, a 'stream' (as described below), is in some ways equivalent to a Git/Mercurial repository. I.e. you can push/pull changes from one stream (or repository) to another; just as you can push/pull changes from one branch to another (with a merge).

If we were to implement the concept of branches and streams, it might make sense to also allow those branches and streams to be external - I.e. add the ability to have multiple repositories and combine the concepts of branch/stream/repository - a grand unified theory I suppose :-). AccuRev has proven that if you have 'streams' - which are just like internal repository copies, then you don't need the old-fashioned 'branch' concept. The ability to remove the distinction between an internal branch/stream/copy and an external repository (as per Git, Mercurial) could be a powerful concept; but I suspect that this may be out of scope for Subversion's design and purpose (?). It could be achieved in one of two ways:
a) add support for internal repository copies into Git/Mercurial.
   (Mercurial has some new feature discussions along these lines: subrepositories, NestedRepositories, and something like overlayrepository idea needed to prevent full-history copies).
b) or add support for internal and external streams to Subversion. (we might like to call them repositories instead of streams).

So...
FEATURE FIVE: support for external streams.
Allow the creation of a stream external to the current repository. This would in effect, create a fully-functional repository copy (in the style of Git/Mercurial), but ideally:
1. Copy only the minimal required data and meta-data for this external stream to be able to operate independently of the original repository.
2. have the option to copy all meta-data, so it really is a fully-independent repository copy; and/or link to the original repo so that additional meta-data can be pulled-down if required.
3. retain information about the originating repository/stream and also internal and external child streams.
4. all features (below) should work across internal and external repositories. E.g. reparenting a stream is akin to telling the current repository to inherit changes from a different (parent) repository.
5. to the largest extent possible, there should be no distinct between an internal stream, and an external stream/repository.

-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
Sent: 03 September 2009 14:28
To: Steve Brown (TCG IT)
Cc: dev_at_subversion.tigris.org
Subject: Re: feature request: dynamic branches (streams)

I'm not able to comment in full regarding this suggestion, Steve, but I did want to encourage you to continue to develop the idea as you have time and ability. Please don't interpret near-silence in terms of responses to your post to mean "We don't care" when the reality is probably closer to "We really would like to focus on getting Subversion 1.7 out the door".

Steve Brown (TCG IT) wrote:
> Now that merge-tracking is almost fully featured in Subversion, it
> seems appropriate to consider what might be the next big step: streams
> (dynamic branches).
>
> AccuRev is a good comparison for this and there is lots of doco on the
> AccuRev website explains what streams are and how they work.
> In simple terms streams are just 'smart branches' - a bit smarter in
> fact than the current PlasticSCM smart branches...
>
>
> The key benefit is the ability to more accurately and easily reflect
> real-world development concepts:
> Consider two branches: what I'll call child-branch and parent-branch.
> In the features list below I use the term branch and stream
> interchangeably but there's really no difference:
>
> FEATURE ONE: promoting commits.
> A child-branch knows it's parent-branch, and developers can 'promote'
> their code up to the parent branch.
> A promote is identical to a trivial merge (ie when the parent branch
> version is an ancestor of your child-branch version, there is actually
> no code-merging needed).
> In this case the 'promote' should be a virtual copy of the file to the
> parent-branch.
>
> Example: parent_branch: the_prod_branch, child_branch: my_dev_branch.
> After working in my_dev_branch you 'promote' your code up to
> 'the_prod_branch' once your unit testing has passed.
>
> If the promote requires a merge, then you perform the merge in the
> *CHILD* branch, and then do the promote up.
> fyi, In AccuRev, code requiring a merge is easily found with the 'stat'
> command when returns a status of 'overlapped'.
>
> Why is this different to a normal merge?:
> 1. Because we record the fact that it was a logical 'promote' of
> the code... the merging 'noise' happens in the child-branches and the
> parent-branch just has a nice clean promote transaction.
> 2. (also see feature four: real vs virtual versions).
>
> You should be able to stop promotions to/from streams by applying
> 'stream-locks' (see accurev for more info).
>
>
> FEATURE TWO: inheritance.
> The opposite of a 'promote' is 'inheritance'.
> The child-branch, by default, automatically inherits the code from the
> parent-branch. This is equivalent to continuously merging the
> parent-branch to the child-branch.
>
> Again, it should be a virtual-copy to the child-branch. If merging is
> required, then those files needed merging are not automatically
> updated, but are tagged as 'overlapped' (see feature 1 above).
>
> You can prevent automatic inheritance by putting a time-lock on the
> child-branch which says "inherit stuff from the parent branch as it
> was at the time-lock datetime". Fyi, AccuRev calls it a "time-basis".
> You can also prevent/freeze inheritance by creating the branch as a
> normal 'static' branch or label/snapshot, so it is frozen in time to
> match the state of the parent-branch at the time it was created.
>
> Example: as above, if someone else puts code into the_prod_branch,
> my_dev_branch will automatically get it.
>
> FEATURE THREE: re-parenting a stream.
> Should be able to drag-and-drop streams.
> I should be able to re-parent my_dev_branch onto a new parent branch,
> and the automatic inheritance (feature two above) will mean I now see
> code from my_prod_branch where I don't have local my_dev_branch
> versions.
> For this to work you probably also need AccuRevs concept of 'active'
> changes. I.e. once you 'promote' code from a child-branch to a
> parent-branch, the child-branch no longer has those files as 'active',
> so inherits the code from it's parent branch instead. (see AccuRev
> doco for how this works).
>
>
> FEATURE FOUR: virtual vs real versions.
> Trivial merges and promotes (see feature one above), give svn the
> ability to record them as 'virtual' copies of the underlying 'real'
> version of the file. If we track these real vs virtual versions in the
> history for the file, then we should be able to compare two
> branches/streams/labels based on their real versions instead of
> virtual versions. This makes it very simple to see the real
> differences between two branches.
> Again see AccuRev doco for how this works.
>
>
> You might also like to read AccuRev's doco on file status. Some useful
> status information that AccuRev can report:
> 'backed': the file in your current branch matches (points to) the
> parent-branch version.
> 'modified': you have a local modified copy of the file
> 'kept': the file has an 'active' change in the current stream
> 'overlapped': the file has changes that will require merges from the
> parent stream.
> 'underlapped': the file is an ancestor of the parent-branch version.
>
> There are other specific complexities like 'cross-promotes' (merges to
> something other than the parent-branch) which I haven't discussed, and
> probably other stuff that I've failed to mention.
>
>
>
>
> Steve
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessage
> Id=2385966

--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2390701