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

Re: svn up should *fail* on working copy whose source url correspond to some other node?

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: Thu, 14 Aug 2008 21:51:30 +0530

Hash: SHA1

C. Michael Pilato wrote:
> Kamesh Jayachandran wrote:
>> Hi All,
>> I deleted issue-2897-take2 branch at r32477 and recreated again it from
>> trunk_at_32477 at r32478. When I ran 'svn up' on my old 'issue-2897-take2'
>> working copy it updated to the new URL which I think is wrong or atleast
>> a new behaviour in trunk.
>> $trunk_svn co
>> http://svn.collab.net/repos/svn/branches/issue-2897-take2@32476
>> $cd issue-2897-take2
>> $trunk_svn up #This should fail, but succeeds as of trunk svn
>> Any thoughts?
> Why it succeeds is easy to explain. Likewise, why it should fail is
> easy to understand.
> With the new location-segments code, it would be easy to write an
> svn_repos_youngest_common_ancestor() function (like the
> svn_client__get_youngest_common_ancestor() I wrote for the client side)
> which could be employed by the dir-delta code and used to verify that
> what-you-have and what-you-want share a single line of history in the
> update case. It could also be used to safeguard the switch case by
> complaining if what-you-have and what-you-want have no common ancestor
> at all (so you don't accidentally switch to some arbitrary tree location).

Yes something of that sort has to happen.

Worse still 'svn up' succeeds even if the new unrelated node at the old
url sharing *no* history with the old node.

With regards
Kamesh Jayachandran
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


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-14 18:22:36 CEST

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