> >
> > 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
Received on 2013-08-15 00:56:28 CEST