On Sat, Apr 23, 2011 at 2:13 PM, C. Michael Pilato <cmpil...@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.
