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
Received on 2009-08-21 14:42:57 CEST