svn commit: r211503 - head/sys/mips/atheros

[Andre Oppermann]

On 19.08.2010 20:42, M. Warner Losh wrote:
> In message:<4C6D6FD7.7060106 at freebsd.org>
>              Andre Oppermann<andre at freebsd.org>  writes:
> : On 19.08.2010 19:20, M. Warner Losh wrote:
> :>  In message:<4C6D2933.9020306 at freebsd.org>
> :>               Andre Oppermann<andre at freebsd.org>   writes:
> :>  : On 19.08.2010 13:53, Adrian Chadd wrote:
> :>  :>   Author: adrian
> :>  :>   Date: Thu Aug 19 11:53:55 2010
> :>  :>   New Revision: 211503
> :>  :>   URL: http://svn.freebsd.org/changeset/base/211503
> :>  :>
> :>  :>   Log:
> :>  :>      Add some initial AR724X chipset support.
> :>  :>
> :>  :>      This is untested but should at least allow an AR724X to boot.
> :>  :
> :>  : Isn't this something that should be done on a project branch and
> :>  : merged back when in a good working state?
> :>
> :>  We don't have a branch for mips stuff these days.  This stuff is OK,
> :>  since the AR724X is just being rolled out right now...  For non AR724x
> :>  systems, this won't affect anything...
> :
> : I was more concerned about tree breakage for non-tested code.  When
> : developing something bleeding edge it is often useful to just commit
> : some stuff and have it sorted out later.  In head this is more
> : dangerous.  A small AR724X development branch would be ideal for
> : this.  Branching is cheap with SVN these days.
>
> Merging isn't that cheap with svn.  The svn:mergeinfo properties make
> them a pita.  Given that this code won't break anything, except
> possibly the now-unsupported AR724x, I think a branch would be
> overkill.  We'd have to drag that branch along all the time until we
> can get actual hardware to test it on, which is a high overhead.

Didn't know that branching and merging isn't that easy with SVN after
all.  This was one of the supposed benefits for switching from CVS.
If there is no risk of head breakage I don't mind at all.

-- 
Andre