On Fri, Aug 6, 2010 at 6:52 PM, Paul Burba <ptbu...@gmail.com> wrote: > On Wed, Aug 4, 2010 at 4:04 AM, Bert Huijben <b...@qqmail.nl> wrote: >> >> >>> -----Original Message----- >>> From: Paul Burba [mailto:ptbu...@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) >>> <servatius.brandt.exter...@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
