In message: <20100308000203.ga70...@dragon.nuxi.org>
"David O'Brien" <obr...@freebsd.org> writes:
: On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
: > In message: <20100307054423.ge70...@dragon.nuxi.org>
: > "David O'Brien" <obr...@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.5...@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.
Warner
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
