Checkout existing branch to established workspace (.moved)

[Eli Zaretskii]

> From: "Bulgrien, Kevin" <Kevin.Bulgrien at GDSATCOM.com>
> Date: Fri, 23 Mar 2012 16:58:45 -0500
> 
> > I believe that in most cases, using the versions from the branch that
> > were all committed together is more likely to produce a set of files
> > that work with each other.  I believe that in most cases, using a mix
> > of on-disk versions and branch version is more likely to break the
> > workspace, because the on-disk versions won't match the branch
> > versions' expectations.
> 
> Wait a minute... If it didn't move files that were different, how would
> it create a "mixed" set of files?

The files would be "mixed" because some of them came from upstream,
while others came from the local tree.  This makes the current branch
state inconsistent.

> I should think that the existing
> buildability state would still be preserved and that any new files
> Probably Would usually not impact the build.

Actually, they could easily break the build.  One immediate example is
that the checkout brings in new files, but the corresponding changes
to the Makefile are not brought in because there's an existing
Makefile in the local tree.  Another similar breakage would be if some
new header is brought in that defines a new layout of a data
structure, but there's an existing file which uses that structure and
defines a different layout for it as part of the file.  (The
underlying use-case would be that in the upstream repo, someone
refactored the code to move the structure definition to a header file,
and then modified the structure layout on that header.)

I believe there's any number of similar scenarios where doing it the
way you suggest, i.e. not moving existing files out of the way, would
not be TRT.