Bert Huijben wrote on Sun, Mar 27, 2011 at 19:26:50 +0200:
> > -----Original Message-----
> > From: Daniel Shahaf [mailto:danie...@elego.de]
> > Sent: zondag 27 maart 2011 0:31
> > To: dev@subversion.apache.org
> > Subject: [PATCH] issue #3469: tree conflict under a directory external
> > 
> > Issue #3469 is about having merge pull in the addition of A/mu when A/
> > is an external.  (File modifications work and raise a tree conflict.)
> > 
> > The following patch attempts to address it by having merge_file_added()
> > skip the addition of files under a directory external.  Thoughts or +1's?
> 
> Your patch contains SVN_DBG() statements

I know, and I intend to remove them before commiting.  Thanks for
pointing it out.

> and there are easier (and more
> performant) ways to check if a node is part of a working copy (e.g. helpers
> to check if a path is switched/a wc root). 

Could you elaborate on these please?  I looked through the header files
and amn't sure which helpers you're referring to.

I think we have to the disk in this case --- since if the file being
added (or any parent thereof) is obstructed, we shouldn't modify the
disk.

> I would drop the term 'disjoint' as it doesn't really apply after moving to
> a single-db working copy system.
> 

Not sure what you mean, it's definitely possible to do

    svn co URL1 foo && svn co URL2 foo/bar/

in 1.7.  If that's not supported, we should make error out (just like we
did for 'svnadmin create' some time ago).

> This patch introduces +- 2 database transactions for every node tested,
> while the wc-root of the merge-target will never change (and will certainly
> be the merge target or an ancestor of it).
> 

Fair enough; I'll make the next iteration of the patch cache
target_wcroot_abspath in the baton.

> If you want the cheapest check you should check if the directory of the file
> has a working copy root above (or at) the merge-target.
> (Performing wc_db queries on a directory is generally cheaper than for files
> as we keep a record for each directory in a hashtable and currently a file
> can never be in a diffent working copy then it's directory)
> 

In other words: whatever check I do (be it the "get wc root" I have now
or something else, per above), I should do it on the dirname() of the
file being added.  Thanks for the tip, I'll make this change in the next
iteration of the patch.

>       Bert
> 

Thanks for the review.  I'll incorporate the two optimizations you
suggested and re-submit the patch once you've clarified the point about
a more performant way to detect a wc root.

Daniel

Reply via email to