change in handling of manifest <copyfile> & <linkfile> directives

[Mike Frysinger]

context: https://crbug.com/gerrit/11218

we've noticed that <copyfile> & <linkfile> in manifests have been a bit underspecified.  we implemented them with semantics that we intended, but never fully documented our intentions.  then someone tried to do something we didn't intend, and it didn't work :).

so we're in the process of clarifying their usage and adding more checks to enforce them.  this might break existing manifests out there, but (based on the original intentions :D), they should never have worked in the first place.

this CL clarified how we intended the directives to work:

  https://gerrit-review.googlesource.com/c/git-repo/+/232893

tl;dr: copyfile & linkfile are declared in the scope of <project>, so they're supposed to be copying files from those projects only, and copying them within the scope of the repo client checkout.

some concrete examples of things you can do today but we're going to break:

- a <copyfile> declared in the context of one <project> that copies files from a completely different <project>

  - we'll still allow copying from nested projects out of laziness

- a <copyfile> or <linkfile> that creates paths outside of the repo client checkout (oops)

- a <linkfile> that points to paths outside of the repo client checkout

  - individual git checkouts can effectively still do this as they can simply commit symlinks

- a <copyfile> or <linkfile> that follows intermediate symlinks in the repo client checkout (src or dest)

- a <copyfile> that copies to or from non-regular files (e.g. fifos)

perhaps also worth noting behavior that doesn't work today, but more because of the way the code is written than because we implemented it explicitly that way:

- a <copyfile> that copies an entire directory

- a <copyfile> that copies a file to a directory without a filename (e.g. dest="foo/")

we will be keeping the behavior where you can implicitly create intermediate directories.  e.g. you may do <copyfile src="file.txt" dest="foo/file.txt"/> where "foo" does not exist in the repo client checkout.  it'd be possible to synthesize this behavior with more <project> entries, so dropping support doesn't gain us anything.

does anyone have a reasonable use case that this would cause problems with ?

-mike