svn commit: trunk/busybox: scripts

Bernhard Fischer rep.nop at aon.at
Sat May 13 19:20:31 UTC 2006


On Thu, May 11, 2006 at 11:18:11AM -0400, Rob Landley wrote:
>On Wednesday 10 May 2006 2:45 pm, Bernhard Fischer wrote:
>> >I should make it run the test suite and show me the failures...
>>
>> You misunderstood what i said.
>>
>> To avoid to put stuff into the repository that you do not want to be
>> checked in and to check if a given changeset is doing what it is
>> supposed to do without relying on any other lingering changes, cp a
>> clean checkout to a scratch-dir, apply the changeset you intend to put
>> into the repo, build, test, and then check in this changeset out of the
>> *scratch* copy.
>>
>> No chance that unwanted stuff ends up being checked in if you use a
>> *separate* cp which *only* contains the one changeset you want to put in.
>
>You were pointing out "make help" breakage and recommending I adopt a 
>technique that wouldn't have caught the "make help" breakage.  This is why I 
>was confused.


No, i wasn't suggesting this. I suggested two completely unrelated
things:

a) isolate patches to be checked in into a vanilla checkout and *test*
  your changes. Checkin from this tested copy where only 1 change lives.
  This avoids leaking unrelated stuff into trunk when comitting tested
  patches.

b) If you want to checking stuff which is *not* tested (like r15043
  http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/Rules.mak?rev=15043&r1=15038&r2=15043
  which results in a completely unoptimized thus useless binary)
  or is not finished, then create you own branch:
  svn cp svn+ssh://busybox.net/trunk svn+ssh://busybox.net/branches/rob
  and check in the unfinished work in your "rob" branch there.
  This avoids breaking trunk by checking in untested or unfinished
  stuff.
>
>Rob
>-- 
>Never bet against the cheap plastic solution.
>



More information about the busybox mailing list