Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 07 Oct 2016 11:02:38 -0700
From:      John Baldwin <jhb@freebsd.org>
To:        Marcel Moolenaar <marcel@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r306811 - in head: etc/mtree include sys/sys sys/sys/disk
Message-ID:  <1910643.6VW4zuRaGg@ralph.baldwin.cx>
In-Reply-To: <201610071542.u97FgLgU092008@repo.freebsd.org>
References:  <201610071542.u97FgLgU092008@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, October 07, 2016 03:42:21 PM Marcel Moolenaar wrote:
> Author: marcel
> Date: Fri Oct  7 15:42:20 2016
> New Revision: 306811
> URL: https://svnweb.freebsd.org/changeset/base/306811
> 
> Log:
>   In order to allow mkimg(1) (and other tools) to become a build tool
>   that can be compiled on various OSes (including on older versions
>   of FreeBSD), make it possible to have it include the partitioning
>   scheme definitions without pulling in FreeBSD specifics.
>   In particular this means:
>    o  move the scheme definitions iand related defines to header files
>       under sys/disk,
>    o  make them (more) portable by using uint#_t (where applicable)
>       and renaming defines so that they at least have a good prefix,
>    o  make the new headers stand-alone so that they don't need FreeBSD
>       definitions, like struct uuid(*)
>    o  keep the original headers for compatibility, but rewrite them to
>       get the scheme definitions from <sys/disk/$scheme.h>.
>   
>   (*) since UUID/GUID type definitions are non-portable and the GPT
>   scheme uses them, make it possible to have the scheme definitions
>   use an external type by allowing consumers of the header to set
>   GPT_UUID_TYPE. When GPT_UUID_TYPE has not been defined, the header
>   will use it's own type definition, which is the same as struct uuid.
>   The gpt_uuid_t typedef is created to abstract the details and allows
>   consumers to refer to a single type.
>   
>   There is not conflict between the partitioning scheme headers and
>   what is defined in them. All headers can be included in the same
>   source files.
>   
>   Note: consumers of the old headers have not been changed yet. Such
>   will be done if and when needed/beneficial.
>   
>   Reviewed by:	imp, jhb
>   MFC after:	1 month
>   Sponsored by:	Bracket Computing
> 
> Added:
>   head/sys/sys/disk/
>   head/sys/sys/disk/apm.h
>      - copied, changed from r306810, head/sys/sys/apm.h
>   head/sys/sys/disk/bsd.h
>      - copied, changed from r306810, head/sys/sys/disklabel.h
>   head/sys/sys/disk/gpt.h
>      - copied, changed from r306810, head/sys/sys/gpt.h
>   head/sys/sys/disk/mbr.h
>      - copied, changed from r306810, head/sys/sys/diskmbr.h
>   head/sys/sys/disk/pc98.h
>      - copied, changed from r306810, head/sys/sys/diskpc98.h
>   head/sys/sys/disk/vtoc.h
>      - copied, changed from r306810, head/sys/sys/vtoc.h
> Replaced:
>   head/sys/sys/apm.h   (contents, props changed)
>   head/sys/sys/disklabel.h   (contents, props changed)
>   head/sys/sys/diskmbr.h   (contents, props changed)
>   head/sys/sys/diskpc98.h   (contents, props changed)
>   head/sys/sys/gpt.h   (contents, props changed)
>   head/sys/sys/vtoc.h   (contents, props changed)

Somehow this destroyed the history on these files.  They showed up as
deleted and then added instead of modified.  If you 'svn log' on them
now you only get this commit and none of the previous history.  I've
no idea if there's a way to recover this?  Had you originally done an
'svn mv' in your checkout and then copied the files back over or some
such?

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1910643.6VW4zuRaGg>