Re: Recurse into same-repos externals at commit time.

On 08/29/2011 08:46 PM, C. Michael Pilato wrote:
> sne-wc-top (an empty wc)
> unversioned
> sne-wc-nested (a different empty wc from svn-wc-top)
> unversioned
> sne-wc-ext (a third, different empty wc, which is an
> external not of its parent, or even of the
> nearest versioned ancestor, or even of any
> item within the nearest versioned wc, but
> of a wc even farther up the tree.)

Hmmm, actually I was wrong assuming that there is no entire separate
checkout in a subdir anymore. Only now do I grasp the vastness of externals
land. * bows to CMike & Bert

I see now that cleanly omitting direct externals targets, no matter where
they are, is difficult. I won't attempt to skip explicit targets ATM, not
before a whole lot more thinking; thanks Mike.

I tested, and this nested stuff looks pretty much like uncharted subversion
land. This could be "The Bermuda Delta", where magnetic fields hide subtrees
from your status and make clients crash, never to be seen again...
There likely are many more problems ATM than I found below. So I guess we
should probably *design* what it should behave like.

As if that was something new.

I guess ideally we want to reserve the term "externals" for those items that
have an explicit svn:externals definition. Don't include other WC-roots with
the --include-externals option. Like this:

Commit:
(1) by default stop recursing at the slightest WC ripples
(2) but if --include-externals is passed, also jump into all the externals
items known to *this* WC by svn:externals definitions
(3) Even with --include-externals, do not step into switched or separately
checked-out WCs that are lacking a matching svn:externals definition in
*this* WC.
(4) '*this* WC' is always closely tied to the target: when an explicit
target is (inside) a dir-external from a 'parent WC', we regard
inside-the-dir-external as '*this* WC', not the 'parent WC'.
(5) Externals coming in from 'parent WCs' are ignored (ideally as unversioned).

And the next mad thing would be --include-nests (or something) that would
recurse through all of unversioned, external'd, switched, separate WCs and
nestings thereof and commit all to their respective proper places.
(And would have to step through all ancestors to find which of its
unversioned files are in fact externals from 'parent WCs')

If interested, here's what I tested with 1.7.x:

  legend:
    UNV: unversioned dir
    V1, V2, ...: versioned dir
    xV1, xV2, ...: dir external of V1, V2, ...
    xfile: file external

When there's a dir external V1/UNV/V2/UNV/xV3 (svn:externals on V1),
curiously, status shows:

[[[
+ svn status V1
X V1/UNV
]]]

Even though the external is way deeper, it appears UNV is the external. Is
that intentional?

I see that this could make sense when there are numerous externals inside
UNV, but maybe we should use some longest_common_ancestor stuff instead, if
we really wanna do that.

Then I tested this with file externals :)

[[[
Fetching external item into 'V1/UNV/V2/xfile2':
svn: warning: W155022: Cannot insert a file external defined on '/tmp/wc/V1'
into the working copy '/tmp/wc/V1/UNV/V2'.
]]]

But setting a file external inside an unversioned dir works. It also causes
a status that shows the unversioned ancestor as 'X', not the file external
itself.

[[[
$ svn up
...
Fetching external item into 'V1/UNV/V2/UNV/xV3':
A V1/UNV/V2/UNV/xV3/v
Updated external to revision 4.

Fetching external item into 'V1/UNV2/xfile':
A V1/UNV2/xfile
Updated external to revision 4.

# make local textmods in both externals

$ echo mod >> V1/UNV/V2/UNV/xV3/v
$ echo mod >> V1/UNV2/xfile

$ svn status V1
X V1/UNV
X V1/UNV2

Performing status on external item at 'V1/UNV/V2/UNV/xV3':
M /tmp/nested_wc_unver_wc.7QJ/wc/V1/UNV/V2/UNV/xV3/v

# file external V1/UNV2/xfile is omitted from this status,
# though the dir external got some special status-attention.
# A direct status on the file external also fails:

$ svn status V1/UNV2/xfile
svn: E155010: The node '/tmp/nested_wc_unver_wc.7QJ/wc/V1/UNV2' was not found.

# svn info is successful on V1/UNV2/xfile, though.

$ svn info V1/UNV2/xfile
Path: V1/UNV2/xfile
Name: xfile
Working Copy Root Path: /tmp/nested_wc_unver_wc.0lP/wc
URL: file:///tmp/nested_wc_unver_wc.0lP/repos/V3/v
...

# commit doesn't bother about either.
# The file external is even rejected as direct commit target:

$ svn ci -mm V1/UNV2/xfile
svn: E155010: Commit failed (details follow):
svn: E155010: The node '/tmp/nested_wc_unver_wc.dDv/wc/V1/UNV2' was not found.

]]]

~Neels