> > > > 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.
No. There is no way to know who is using a fork you may have created or who has forked from someplace (short of scanning all projects of course). I'm not sure fork is the best name to give this concept, but we didn't want to choose branch or tag for obvious reasons....
