On Thu, Aug 15, 2013 at 6:09 PM, <dlel...@rockwellcollins.com> wrote:
>
> If a project doesn't want to accept a change, they "fork" to a new
> "history". The tool does this with a svn cp <old_pedigree/foo.c>
> <new_pedigree/foo.c> and an update to the svn:externals property. They now
> lose sight of what the other project commits after that fork though. The
> backend of where the file is stored and how is masked by the tool.
> <pedigree> is essentially implemented as a folder. To the developer, they
> may know that their file is really a file external, but they don't treat it
> really any different from a normal file until it comes time to "fork". I
> try to differentiate "forking" as a pedigree/history from branching and the
> like.
>
> This system is essentially an implementation of Rational's CMVC history
> feature.
In subversion's view a copy is a branch so any distinction is strictly
your own convention. Likewise for tags, except that there is a
generally accepted convention of not committing changes after a tag
copy. Do you have additional conventions or tools to help users of
the pre-fork version know that it has branched? I don't think there
is a generic solution for that - subversion tracks copy-from history,
but not copy-to.
--
Les Mikesell
lesmikes...@gmail.com
