[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 14 Aug 2008 11:50:40 -0400

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).

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-08-14 17:50:56 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.