svn: head/usr.sbin/mergemaster

Ken Smith kensmith at cse.Buffalo.EDU
Thu Jan 1 22:58:46 PST 2009

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      |       kensmith at
  there, funny things are everywhere.   |
                      - Theodore Geisel |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url :

More information about the svn-src-head mailing list