[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Externals inconsistencies and feedback

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Wed, 27 Aug 2008 15:17:41 -0400

Blair Zajac <blair_at_orcaware.com> writes:
> If you delete a directory created by an external and then do an 'svn
> up' it'll restore it since update passes TRUE as update_unchanged to
> svn_client__handle_externals(). However, if you switch to the same
> URL, then it won't restore it since it passes FALSE.
> $ svnadmin create repos
> $ svn co file://`pwd`/repos wc
> Checked out revision 0.
> $ svn ps svn:externals
> 'http://svn.collab.net/repos/svn/branches/file-externals/contrib/client-side/svnmerge
> svnmerge' wc
> property 'svn:externals' set on 'wc'
> $ svn ci -m '' wc
> Sending wc
> Committed revision 1.
> $ svn up wc
> Fetching external item into 'wc/svnmerge'
> A wc/svnmerge/svnmerge.sh
> A wc/svnmerge/svnmerge-migrate-history.py
> A wc/svnmerge/svnmerge-migrate-test.sh
> A wc/svnmerge/svnmerge.README
> A wc/svnmerge/svnmerge_test.py
> A wc/svnmerge/svnmerge.py
> U wc/svnmerge
> Updated external to revision 32677.
> Updated to revision 1.
> $ ls wc/
> svnmerge
> $ rm -fr wc/svnmerge
> $ svn switch file://`pwd`/repos -r HEAD wc

This was a no-op switch here, right? That is, you're just running it to
show us how 'switch' doesn't restore the missing externals dir, even
though 'update' would, right?

> At revision 1.
> $ ls wc | wc
> 0

> Another issue, in externals.c compare_external_items(), I don't think we can
> return that two external items are identical if either the old or new external
> item has a HEAD peg revision, since a new HEAD revision may have replaced the
> item with another item.

Excellent point; I cannot imagine disagreeing :-).

> So I think we should just get rid of the update_unchanged argument to
> svn_client__handle_externals(). We should always update externals. I can't
> think of a time when you wouldn't want to.

I wish I could remember why we added it, but what you're saying seems
reasonable now, yes.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-27 21:18:02 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.