On Aug 14, 2013, at 17:55, dlellis@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.)
|