On Aug 14, 2013, at 17:55, dlel...@rockwellcollins.com wrote: >> 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.
>> 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. No one else would see it with externals either, except that you wrote a custom tool to analyze the externals, see if a newer revision of the original exists, and show that to the user. If you can do that with externals, you can do that with copies too. (Use "svn log --stop-on-copy" to find out where the copy came from, then see if there are newer revisions of that.)
