You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2008/08/14 15:24:45 UTC
svn up should *fail* on working copy whose source url correspond
to some other node?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All,
I deleted issue-2897-take2 branch at r32477 and recreated again it from
trunk@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?
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIpE483WHvyO0YTCwRAmFJAJ9jRhH1btaBnTdKZKKcyw9E/UYItgCfTMv9
/TMncq7FZUGFSGxOq7XLcfo=
=2gfP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn up should *fail* on working copy whose source url correspond to some other node?
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Aug 14, 2008 at 12:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
> 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.
I am/was just a little concerned someone would run off and take this a
way. I also recall one time I was deleting something in the repos
using a GUI, and I had my branches folder selected and did not know
it. So I deleted all of my branches. svn copy allowed me to recreate
it easily, but it would have sucked if all users had to use switch or
checkout again.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn up should *fail* on working copy whose source url correspond
to some other node?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Thu, Aug 14, 2008 at 12:21 PM, Kamesh Jayachandran <ka...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn up should *fail* on working copy whose source url correspond to some other node?
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Aug 14, 2008 at 12:21 PM, Kamesh Jayachandran <ka...@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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn up should *fail* on working copy whose source url correspond
to some other node?
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
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@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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIpFuJ3WHvyO0YTCwRAoDwAJ9kLirxLpMfYz94VIL5XHCHh5zTWwCfW89G
l0q9WIsstoxSU1b3ClJLULA=
=MbBR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn up should *fail* on working copy whose source url correspond
to some other node?
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> Kamesh Jayachandran wrote:
>> Hi All,
>>
>> I deleted issue-2897-take2 branch at r32477 and recreated again it from
>> trunk@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).
WARNING: This way likely lies great performance pain for 1.4-era (and
older) repository formats which lack the node-origins cache support.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn up should *fail* on working copy whose source url correspond
to some other node?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Kamesh Jayachandran wrote:
> Hi All,
>
> I deleted issue-2897-take2 branch at r32477 and recreated again it from
> trunk@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand