Re: Mergeinfo not inherited due to file externals

[Paul Burba <pt...@gmail.com>]

On Fri, Aug 6, 2010 at 6:52 PM, Paul Burba <pt...@gmail.com> wrote:
> On Wed, Aug 4, 2010 at 4:04 AM, Bert Huijben <be...@qqmail.nl> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Paul Burba [mailto:ptburba@gmail.com]
>>> Sent: dinsdag 3 augustus 2010 22:50
>>> To: Brandt, Servatius (External)
>>> Cc: Subversion Development List
>>> Subject: Re: Mergeinfo not inherited due to file externals
>>>
>>> On Mon, Jul 26, 2010 at 4:50 AM, Brandt, Servatius (External)
>>> <se...@ts.fujitsu.com> wrote:
>>> > A merge into a directory with a file external shows the following
>>> > problems:
>>> >
>>> > 1) mergeinfo at the directory is not inherited (and all files and
>>> >   subdirectories get their own inheritable mergeinfo).
>>> >
>>> > 2) mergeinfo is added to the external file.
>>> >
>>> > The mergeinfo at the external file is just wrong and useless, and 1)
>>> > will cause problems on a reintegrate merge.  A use case and an
>>> example
>>> > are following.
>>>
>>> Hi Servatius,
>>>
>>> What's happening here is that the merge tracking logic erroneously
>>> treats externals the same as switched subtrees and sets mergeinfo to
>>> segregate the "switched" subtree, so if it is later unswitched, it
>>> doesn't inherit mergeinfo from the root of the branch which was never
>>> actually merged.  This is fine for switched subtrees, but I agree with
>>> you, it doesn't make much sense for externals (which might not even be
>>> from the same repository!).
>>
>> Currently file externals *must* always be from the same repository, because they are just switched files with a bit of special UI on top of them. (See the original introduction text of file externals)
>
> Hi Bert,
>
> What introduction are you speaking of?
>
>> We didn't fix this limitation for WC-NG yet, even though we should be able to describe a new working copy for just a file. (An issue would be that we can't use the normal update editor to describe changes on just a file, but that is easy to work around)
>>
>> I think you can assume that for a file-external no unswitched BASE_NODE exists, while for a normal switched path there most likely is a BASE node.
>
> When I use svn_wc__db_read_info() to query a file or directory
> external from the same repository, I get back have_base=TRUE.  Is this
> what you meant?
>
> The inelegant fix here is to just use
> svn_wc__internal_is_file_external() in svn_wc__check_wc_root() to
> detect file externals masquerading as switched subtrees.  The latter
> function is how the initial walk of the merge target (with
> svn_wc__node_walk_children) detects switched subtrees at the start of
> a merge.  Directory externals are skipped by
> svn_wc__node_walk_children, so this change would be sufficient to make
> svn merge ignore all externals as far as recording mergeinfo
> describing a merge goes, but it would still let
> svn_wc__check_wc_root() report directory externals as switched.

Forget about *any* fix.  The move to a single DB means our walk to
find subtrees of interest (using svn_wc__node_walk_children) never
visits external subtrees.  So we never mistakenly regard these as
switched, heck it never regards them at all!  I added a simple
regression test to catch any changes in this space
(http://svn.apache.org/viewvc?view=revision&revision=992114), but for
now this is fixed in 1.7.

Paul