If you look at the value of an svn:externals property, it looks a lot like a
shell script. That is, it gives the distinct impression that you're going to
get a bunch of extra checkouts executed in a specific order.
Of course, that's not actually what the implementation does. It parses the
property value into a hash, and then the checkouts happen in an unpredictable
order when looping through the hash.
This can burn users, certainly. Someone in IRC had an svn:externals value like
this:
X URL1
X/Y/Z URL2
Now, what they *expected* to happen was a checkout of URL1 into a newly-created,
versioned subdirectory named X. (It just so happens that such a checkout would
also create a versioned directory Y.) Then they expected a checkout of URL2 to
happen in a newly-created, versioned directory Z. Z would essentially end up as
a happy nested working copy, even though it's "disconnected" from Y. A totally
reasonable expectation.
But instead, they got the checkouts in reverse order. First X and Y were
created as *unversioned* directories, followed by a checkout into newly-created
Z. Then a checkout into X happened, but the unversioned Y directory obstructed
the checkout from creating a versioned Y. Yucky failure.
Anyway... the point here is that we really ought to change the implementation to
guarantee the ordering of external checkouts and updates.
Bug
Major