Mark Phippard wrote:
> On Thu, Aug 14, 2008 at 12:21 PM, Kamesh Jayachandran <kamesh_at_collab.net> wrote:
>>> 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.
>
> I do not get why we would want it to fail. I have always thought this
> was a good thing and even recommend it to people in terms of
> recreating a branch after reintegrating it.
It was suggested in IRC that a warning would be in order. And yes, while
your use-case is one in which the situation turns out for the good, it's
easy to consider other use-cases where that's not true. While I think
erroring out is fine, there should certainly be a way to override the
failure and assert that you know full well what you're doing so please do
the update thank-you-very-much, sir.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-08-14 18:27:46 CEST