On Wed, Mar 28, 2018 at 7:48 PM Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>
> No, you do not need to change your externals. I believe your
> understanding is correct, and I think Branko was incorrect. Indeed, in
> the absence of an operative revision, the operative revision defaults
> to the peg revision (so it does not follow it forward to HEAD), also
> in externals definitions. The peg revision is sufficient to "pin" the
> externals. I just tested this with a test repository with svn 1.9.4.
Thank you. That is reassuring. We have not
changed anything yet.
However, the problem Jonathan saw is, I think, because he renamed a
> parent path that is outside of the scope of the relative path of the
> externals definition. Looking at his example:
Yes that makes sense.
Fortunately for us, all of our externals begin
with "^/SVN/" so we are unaffected by the
relative directory question. I think that when we
designed our monorepo we thought that we
may want to restructure in the future, e.g.
move or rename project directories, combine
projects, split projects, declare projects
defunct, etc. So we did not rely on the relative
placement of projects to each other, but we did
use the caret notation without a URL scheme
to ensure the repository itself is portable. So,
absolute paths within the repository with peg
revisions, relative path to the repository itself.
I think the externals processing sees "../fold1_at_18", and apparently it
> first converts the relative path into an absolute path by looking at
> HEAD ... so "../fold1" becomes "/name2/fold1". Then it sees the peg
> revision, so it wants "/name2/fold1_at_18", which does not exist (at the
> time of @18, the parent folder was name1). Adding an operative
> revision "-r18" does not help.
>
> I'm not sure if this behaviour is "as designed", or whether it should
> be considered a bug. I'm inclined to think it's a bug. The "relative
> url -> absolute url" conversion should probably also take the peg
> revision into account.
It makes intuitive sense that ../fold1_at_18 should
Do The Right Thing. But if it takes "." and expands it to a full path, then
strips off the last
component, then applies the peg revision, that
will explain the source of the issue.
Part of the problem is trying to locate
something in space and time starting from a
leaf rather than the root. The leaf moves
around; the root stays put.
With the peg revision you usually know the full
path that existed at some point in the past, so
Subversion can pull up that revision and
traverse down the tree to the correct location.
But in this case you're starting with a leaf in
some revision so you have to take "." and
expand it to the full path in that revision, then
traverse its history back to the peg revision to
figure out what its full path was back then, and
then go on to strip the last component etc.
The problem is, what revision do you use to
expand "." to the full path? HEAD? BASE? The
way I see it, if it's HEAD and you check out an
old revision, and things have moved around
some more since then, I think you'll encounter
the same kind of breakage.
Nathan Hartman
Received on 2018-03-29 05:49:47 CEST