On Fri, May 21, 2010 at 12:54:31PM +0200, Bert Huijben wrote:
> See the relegate_external() test in externals_tests.py for some ideas on how
> to test this.
I'll do that, thanks.
> > > I think fixing issue ##2267 needs a good design instead of a quick and
> > > dirty fix in one of the fundamental editor helper functions. (E.g.
> > > does this break backwards compatibility of our APIs somewhere?)
> > I don't know. But we usually don't have APIs with strict promises
> > that would forbid svn to do something in addition to what it is
> > currently doing.
> I don't think we can make update perform a commit (or format your hard
I should have added "within reasonable limits" to that sentence :)
Though of course people have different ideas about such limits.
> Your change makes it impossible to start ignoring WORKING_NODE, because
> libsvn_client seems to need it. (Maybe we should remove the entire externals
> reporting from this internal function and handle it in a separate step and
> from the deprecated api version)
I like the idea of separating the base table crawl from externals
handling. Since not all external information can be gathered during
this crawl, the crawl currently does double duty.
In 1.6.x these crawls were expensive, so it made sense to do as much
as possible during a single crawl. But in wc-ng we'll eventually be
crawling just database tables so it should be fine.
> > Note also that in the issue the reporter says:
> > Note that TSVN does fetch the externals in this situation
> > (a temp workaround for me at least).
> > This was in 2005. So I believe that if pulling externals into
> > newly added dirs causes real problems, we'd know about them by now.
> You changed the crawler; not 'svn update'. TSVN just fixed update.
Right. So I guess you would not mind a fix within the CLI client?
> Did you check all the crawler users (in and outside the Subversion
> Or we make it ignore all added nodes and handle the externals handling in
> libsvn_client via some different api. (or ...)
I'll try this approach.
It makes an 1.6.x backport unlikely though.
It's probably not worth the effort.
Received on 2010-05-21 14:13:47 CEST