On Fri, May 10, 2013 at 10:42 AM, Andrew Reedick
<[email protected]> wrote:
>
>> Isn't this just a difference in subversion's and your thinking about
>> the significance of the path change? Subversion is going to see the
>> path change affecting everything below it because of the way it holds
>> projects together. Is there some reason you are changing a common
>> parent path and thinking that it should not affect everything below?
>> Is it 'above' what you think of as the actual project?
>>
>
> Two words: meta data. A change in meta-data shouldn't change a branch's
> baseline. Moving "/trunk" to "/project1/trunk" shouldn't change the contents
> of the trunk baseline. Renaming a misspelled branch (/branches/rle1.0 to
> /branches/rel1.0) shouldn't change the contents of a branch/baseline.
>
How/why do you think of that differently than doing a similar
directory move/rename somewhere under trunk?
> So, from a technical point of view, where "svn has dirs, not branches," then
> yes, I would expect a parent dir change to do what it did. From a
> process/philosophical point of view where branches represent baselines, then
> I would not expect a parent dir change to do what it did.
You think some directories are magically different (i.e. where your
idea of a 'project' starts). Subversion doesn't.
> Anyway, it represents just one more potential quirk that you have to be aware
> of when using svn. Fortunately, it's mostly harmless. Long term, once svn's
> lower level features are mature (true renames, getting rid of --reintegrate,
> etc..) I would expect a push towards high-level process features such as
> branches as first class objects.
I think it is one less thing to think about when all directories are
handled the same way.
--
Les Mikesell
[email protected]
