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 changing.
> 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&dsMessageId=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=2390650