propose: all arch move into a separate dir
David O'Brien
obrien at FreeBSD.org
Mon Mar 8 00:02:13 UTC 2010
On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
> In message: <20100307054423.GE70613 at dragon.NUXI.org>
> "David O'Brien" <obrien at freebsd.org> writes:
> : On Fri, Mar 05, 2010 at 09:41:40AM +0000, Robert Watson wrote:
> : > On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
> : >> In message <alpine.BSF.2.00.1003050912340.5181 at fledge.watson.org>, Robert
> : >> Watso n writes:
> : >>> Doing that kind of rearrangement [...] would be a nightmare for anyone
> : >>> with large [...] patches, so I'd say we could pretty much rule that out
> : >>> outright.
> : >>
> : >> I would say that we should do it occasionally, to encourage these
> : >> FreeBSD users to contribute as many of their local changes back to
> : >> the project, as possible :-)
> : >
> : > Absolutely -- and rearranging a tree is a good way to invalidate
> : > all those patches as well :-).
> :
> : No, not it isn't. Provide a script to convert path's in the diff.
> : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.
>
> You are joking, right? This would be a nightmare for people that
> integrate early and often.
No I am not joking. I was responding to the point that a large patch
(that is a the output of running '$SCM diff') can be easily modified to
match a new directory layout. Thus patches in GNATS aren't "useless".
I'm not sure what operation you are specifically speaking to . But, if
FreeBSD were to move the CPU directories under 'arch/', at $WORK we would
do:
cd sys
mkdir arch
svn add arch
svn mv {list of dirs} arch
svn ci
and be done with it. Branches would merge that change - get a trivial
tree conflict, resolve it - and move on with life.
I would expect folks working in project branches to do the same.
For merging changes from FreeBSD HEAD to FreeBSD stable - that is
trivial:
cd sys
svn merge -c $GRN ^/head/sys/arch/amd64 amd64
svn ci
Subversion makes this a lot easier than CVS did.
--
-- David (obrien at FreeBSD.org)
More information about the freebsd-current
mailing list