In article <mailman.8270.1395195147.18130.python-l...@python.org>,
Tim Chase <python.l...@tim.thechases.com> wrote:
>On 2014-03-18 21:38, Terry Reedy wrote:
>> At least with hg, one should best test the code in the working
>> directory *before* committing to the local repository.
>
>I don't know if this is a hg-vs-git way of thinking, but I tend to
>frequently commit things on a private development branch regardless
>of brokenness, but once I get it working, I flatten & clean up those
>changes ("rebase" in git terms, which I believe has been adopted as a
>standardly-available-but-not-enabled-by-default module in hg) into
>logical units of change-sets that I then test individually before
>applying them to my more public-facing branch. This produces clean
>history that makes it easy for others to see what's going on.
I see it this way that all code is broken to at least a small
extent, so it is stupid to not to save into source control because
code is not yet flawless.
I use RCS (!) for my eulerproject.net programs, and
I save every small milestone. There is just one important rule,
if you save code that has (severe) restrictions, keep
track of it in the submission message, otherwise you loose your
bearings.
Basically the first ten of so versions (before the tag WINNER)
just don't solve the problem.
(Of course euler problems are hard, three rewrites are not
uncommon.)
I compare the in between versions with the nails they put in
the mountainside in climbing. It is a point below which you'll
never need to slide back.
>
>-tkc
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
--
https://mail.python.org/mailman/listinfo/python-list
