On Sat, Apr 23, 2011 at 2:13 PM, C. Michael Pilato <cmpilato_at_collab.net>wrote:
> On 04/22/2011 11:40 PM, Daniel Becroft wrote:
> > But then you're
> > asking to switch a working copy which reflects trunk's *parent
> directory* to
> > trunk's URL.
> >
> >
> > Once trunk is committed, shouldn't trunk share ancestry with it's parent?
> (I
> > know I certainly share ancestry with my father).
>
> Wrong "ancestry" concept. This is version control ancestry, not directory
> hierarchy. Trunk has a unique "line of history". Later, if you make a
> copy
> of trunk and call it, say, "branches/my-branch", that is a fork in trunk's
> line of history. It may be said of "branches/my-branch" that it shares
> version control ancestry with "trunk".
>
Ah, gotcha. My bad.
> > This process worked under 1.6.x (and 1.7.x prior to the last svn update
> -
> > couldn't tell you the revision prior to that).
>
> Yes, your very simplistic use-case would have "worked" in every release
> back
> to 1.0, even. But as we continue to bring Subversion into maturity, we're
> trying to shut down default behaviors that have a history of causing people
> alot of grief. This is one such area. I can't tell you how many times
> I've
> seen someone (including myself) do:
>
> $ cd /path/to/trunk-working-copy
> $ svn switch ^/branches
>
> when what was *intended* was:
>
> $ cd /path/to/trunk-working-copy
> $ svn switch ^/branches/SOME-SPECIFIC-BRANCH
>
The result is disastrous, as Subversion tries to transform a trunk working
> copy to reflect the branches directory -- deleting all of trunk's content,
> and then trying to add every branch in the whole project to that working
> copy.
>
> 'svn switch' was conceived to be Subversion's answer to 'cvs up
> -rBRANCH_NAME' -- Subversion's way to switch between branches -- not just
> some generic point-the-working-copy-wherever-you'd-like mechanism. We now
> have the power to enforce that in ways that were impractical years ago, so
> recently (after another fat-fingered-then-interrupted 'svn switch' left me
> with a corrupt working copy) I added that enforcement, but, as you noted,
> with the ability to disable that safety mechanism via the --ignore-ancestry
> switch.
>
I guess I can understand the reason behind the change. It was just a tad
weird seeing it pop up for a case that has always worked.
Apologies for the noise.
Cheers,
Daniel B.
Received on 2011-04-23 11:11:59 CEST