On Fri, May 10, 2013 at 8:40 AM, Andrew Reedick
<Andrew.Reedick_at_cbeyond.net> wrote:
>>
> It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.)
>
> I can understand why it happens; svn log needs to know about the parent dir rename in order to know (and print) the correct paths for subsequent revisions. It's a mostly harmless side effect of copy/mv, but it is odd looking and seems sloppy from a purist point of view because something outside of the branch is changing the branch's history and baseline albeit in a mostly limited fashion.
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?
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-05-10 17:00:06 CEST