On Wed, Aug 14, 2013 at 5:14 PM, <dlellis_at_rockwellcollins.com> wrote:
>
>>
>> So the point is to intentionally pull the HEAD revision of a whole
>> bunch of files together where each is located arbitrarily and can
>> change independently? I guess that's about the opposite of the way I
>> think of version control, so I can't suggest anything else. Are
>> there enough different 'top level' collections or a fast enough change
>> that you can't simply copy the right files into place instead of
>> having external references there?
>
> 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.
> 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.
> 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?
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-08-15 00:44:29 CEST