Re: propose: all arch move into a separate dir

On Sun, Mar 7, 2010 at 4:49 PM, M. Warner Losh <imp_at_bsdimp.com> wrote:
> In message: <20100308000203.GA70486_at_dragon.NUXI.org>
>            "David O'Brien" <obrien_at_FreeBSD.org> writes:
> : 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".
>
> It seems like it would be a nightmare for anybody tracking the system
> on a regular basis.
>
> : 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.
>
> And everybody who was tracking FreeBSD with their own changes would
> have to scramble.  It wouldn't be trivial by any stretch of the
> imagination.  The project is much larger than svn, and svn doesn't
> lend itself well to having external agents track it.
>
> : 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.
>
> Just because the task is doable with svn, where it was impossible with
> CVS doesn't mean there wouldn't be a significant amount of pain to the
> folks using FreeBSD.  It is cool that Juniper kinda has it worked out,
> but even there I'm skeptical about your claims.  Especially since
> Juniper imports source rarely, where as other firms do it more often,
> and there'd be more pain for them.

    There are also folks (like Ironport) who don't import changes back
into the tree as often, and I'd rather not put more of a crimp on
folks' time for getting things back in because of this forced CVS ->
SVN upgrade (I'd rather convince others gradually over time to switch
to svn as opposed to using CVS).
    As long as CVS continues to be in base, some folks will prefer it
over SVN (not saying because it's better, but just because it's there
and it's established).
Thanks,
-Garrett