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

Re: svn commit: r1089856 - /subversion/trunk/subversion/tests/cmdline/switch_tests.py

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 08 Apr 2011 08:30:02 -0400

On 04/08/2011 04:48 AM, Philip Martin wrote:
> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>> On 04/07/2011 08:44 AM, Philip Martin wrote:
>>> I'm not really sure how a copied switch should behave when committed, is
>>> the above correct?
>> This use-case doesn't even make sense to me. Switch is a working copy
>> operation concept -- causing local elements to reflect an alternate line of
>> history.
>> Forgetting the copy operation for a second, if you simply commit in a
>> working copy that has a switched subdir, there's no "coalescing" of the tree
>> on the server side -- changes made in the subdir wind up in the repos tree
>> to which the subdir is switched, and changes made outside the subdir wind up
>> in their respective original repos locations. Now we add 'copy' to this
>> situation -- a copy of a tree with a switched subdir. I rather think that
>> this should behave as if it was a BASE deep copy with the switches
>> re-applied after the copy. In other words, when looking at the copy result,
>> switch followed by copy should have the same effect as copy followed by
>> switch, or something like that.
> Not sure I understand. Are you saying that "copy then switch then
> commit" should be the same as "copy then commit then switch"?

I'm suggesting that "copy A Z; switch Z/D; commit Z" should be the same as
"switch A/D; copy A Z; commit Z". In other words, stop treating a switch
like a local mod. A switch isn't a local mod -- it's a client-only view
option, kinda like a sparse directory is. Or just say, "Sorry, I can't do
that copy, because you won't get the result you might think you'd get."

> We do have precedent for preventing copies: we disallow copies with
> absent (excluded by authz) nodes, since the server does not allow the
> parent of an absent node to be copied.

... and yet we allow copies of directories locally configured to be
--set-depth=empty, where the result on the server is a full recursive copy.
 Yes, I even pushed in favor of that use-case recently. But now I'm not so
sure. I think the average user's expectation is always going to be, "If I
do a copy, the result will look just like the original did at the time of
the copy." We can't promise that today in many cases. Still, folks are
making use of those very cases. So now I've gone and split my mind about
the matter. :-\

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

Received on 2011-04-08 14:30:40 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.