svn: head/usr.sbin/mergemaster

[John Baldwin]

On Friday 02 January 2009 1:58:29 am Ken Smith wrote:
> 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.

It would be really nice if we could fix the CVS importer to not work this way 
somehow.  Maybe it could just ignore the 'cp' instead of doing a checkin 
somehow?

-- 
John Baldwin