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