On Thu, 2009-01-01 at 22:44 -0800, Maxim Sobolev wrote: > Doug Barton wrote: > > Given that this is a situation that comes up very infrequently (usually > > only for a major version upgrade) and can usually be handled simply > > enough on a one-off basis, I will once again point out that I think > > this is a Bad Idea. I would be willing to consider a better implementation > > as an option that is off by default. > > You are very wrong on this. This situation happens very *frequently* > even for updates between minor releases (such as 6.3 to 6.4 and so on). > As somebody doing lot of source upgrades frequently I can tell you this > for sure. > > -Maxim
Just FWIW...
What triggers it is creating a new branch tag. At the point we create a
new releng/<something> in svn I need to have created the corresponding
branch tag in the CVS repository first (e.g. RELENG_7_1 for releng/7.1).
But then the svn2cvs exporter proceeds to check every file from
releng/7.1 in to RELENG_7_1.
So, you notice it the first time you try to upgrade into a new branch.
Once you're in the branch updates get handled as you'd expect, just
updating any of the files that have changed since the branch got
created. And it doesn't happen with for example the tags that get
created for the release (e.g. RELENG_7_1_0_RELEASE) which are "normal
tags" as opposed to "branch tags". The exporter ignores the release/
tree in svn.
--
Ken Smith
- From there to here, from here to | kensm...@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
signature.asc
Description: This is a digitally signed message part
