On Fri, Aug 21, 2009 at 14:38, Steve Brown (TCG
IT)<Steven.Brown_at_macquarie.com> 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 ZERO: subversion knows what a branch is.
The information about which sub-trees of the repository are intended
to represent branches (& tags) should be available in the repository,
not just be in developers heads. A minimal approach might be 'tag' and
'branch' subcommands which combine copy with setting a property
recording the user's intent on the newly created (...um...) codeline.
> 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
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2386020
Received on 2009-08-21 16:26:52 CEST