> > > > No HEAD revisions, all files are pegged. > > > > For example, if everyone is linked to a common file (foo.c, revision 20, > > project A "pedigree") and a bug is fixed, each project will see that a fix > > has been made. Each project has to make a decision: to remain on the > > current revision (no budget or schedule to update), update to the latest (if > > they have budget and schedule), or to "fork" (if they don't like the fix and > > have to implement a new feature). This can happen any time, not necessarily > > when the file is committed. > > Then what makes the collection of pegged externals easier to manage > than explicitly copying specific revisions into the top level where > the reference makes it appear and subsequently merging changes or > deleting files and copying in the updated version. Those operations > are relatively efficient with svn and copies carry along the revision > history. > > I don't follow how each project 'sees' that fixes have been made - you > shouldn't see that through a pegged external.
We have a tool that mimics explorer. It queries the repo for the latest revision on each file external (yes a bit talky with the server). If they are not identical, it displays revision x of y. It also displays the pedigree (or "history"" in CMVC lingo). You can select each file, and graphically decide to "fork" to a different pedigree/history, or peg to a different revision. > > Each new project inherits the externals from their baseline (they do not > > create new links or go out and search for reuse - that'd be a pain!) So > > until a project decides to "fork" a file, they see (but not automatically > > receive) all the changes made to that file. Nothing happens to your project > > without explicit action. > > You'd get roughly the same effect with an 'svn cp' of a baseline - the > equivalent of a branch or tag even if you name it something else. I don't think this will do what we want. > > > Each file lives in a special area of the repository that identifies its > > pedigree. Code your project writes automatically becomes usable by any > > other project. > > None of that would need to change regardless of whether you copy a > revision into a different folder of reference it directly with an > external. As long as you aren't floating to the HEAD version you > have to do something to bump the revisions - why not just copy it in > the repo where remote revision checks will be fast? Once you copy, you break the link. If you were to make a change to the copy, no one else would then see it. You are correct, you could replicate all of this many different ways. When we did our study, externals (aside from the performance issue) was the best answer. I wish I could give a quick tour of the process/tool. It'd answer so many questions. Thanks, Dan
