Ok, in an attempt to provide a short example:
The code is working, I have tests, yet I don't test for memory leaks.
That's my current scenario. A code snippet follows:
void functionA() {
char *thisWillLeak;
...
thisWillLeak = malloc(1024);
...
// never free nor return the memory
}
void functionB() {
functionA();
}
Then I start to work in a new feature, and I add 10 functions (I will only
show one here).
void functionA() {
char *thisWillLeak;
...
thisWillLeak = malloc(1024);
...
// never free nor return the memory
}
void functionB() {
functionA();
}
void functionC() {
for (i = 0; i < 12000; i++) {
functionA();
}
}
When I run the code it crashes (as it's running on a device with 8Mb of
RAM). I check the why... and I discover that thisWillLeak was never freed.
I'm busy working, so I accidentally add the free in the middle of my work
day, and continue to work on my new feature.
Today is a code freeze, and even when my new feature is not going to be
included, as is not complete, 4 hours later I think "hum, that memory leak
made my software crash because it tried to make 12000 allocations... but in
real life, if functionB, which runs every 5 minutes, gets called around
8192 times, it will surely make the system crash too, so that bug would be
a nasty one given less than a month"
So including that patch right now seems really important. But I have a mix
between the patch and the unfinished (and also untested).
Until yesterday, what did I do?
fossil stash snapshot
go to the editor, find the lines that I want to remove (all the ones from
the new feature), remove them.
test
commit
fossil stash pop
continue working as usual.
But there has also been times where I was working in some document (I use
LaTeX from time to time).
So I have a partial document on the repo. I continue committing every time
I add a new section. I'm in the middle of a section, and some friend kindly
pass by my computer and reads the document directly from the screen. Finds
a typo... I edit it right there (I'm not going to tell him... wait while I
go to the terminal and stash my current work so we can fix the typo,
normally I even forget I can do it while I'm doing the work all by
myself)... then after I finish the section, I do:
fossil diff
just to discover... ouch, I have this uncommitted typo fix too... I don't
want to commit both changes at once... so I need to go and repeat something
close to the previously described workflow.
The change in the first example (only adding a line with a free) seems
trivial, but sometimes there is more than 1 line involved and they are not
all together. Sometimes both the fix and the new feature are completely
independent, ie: instead of a leak, I find a way to rewrite 20 lines of
code, all scattered around, that make functionA a lot more efficient in
execution time than the actual code.
As functionC calls it 12000 times... improving speed execution of functionA
will reduce the time I must spend waiting for the test of functionC ends
(which I run several times as the new feature gets completed). So I
replaced it in the heat of the moment,without stashing... first commented
the line that uses functionC ran the program, worked faster... got happy,
I'll go to bed earlier, uncommented the call functionC and continue to
work...
At the end, I do a fossil diff... and I get the picture... both the speed
improvement idea and the new feature are mixed together...
I can proceed to stash either the speed improvement code or the new
feature, test the one that is not stashed, commit it after I'm happy, pop
the remaining code, and keep going.
Please forgive me if these examples seem trivial or too specific. I tried
to put 3 ones that come to my mind right now.
To finish the idea, I will use another example (this time generic).
touch a.txt
fossil ci -m "a is empty"
fossil add a.txt
echo "dog" >> a.txt
echo "cat" >> a.txt
echo "parrot" >> a.txt
echo "house" >> a.txt
echo "car" >> a.txt
fossil diff
I get
Index: a.txt
==================================================================
--- a.txt
+++ a.txt
@@ -0,0 +1,4 @@
+dog
+cat
+parrot
+house
+car
I discover that the animals, even when it should go into that file,
shouldn't go in the first commit). So I do:
fossil stash save --selectively -m "This stash removes the animals"
Somehow this (perhaps on the same way git does the add --edit, by opening a
text editor with the diff) let me deselect the lines that say "house" and
"car"... and bang. The commit can proceed only with house and car... then I
do fossil pop... that inlcudes the animals... and I can commit again, the
final version of the file.
The main question remains... is there a way to do that "selectively" thing.
Would stash the best place to add it. Is is possible to do so? And the most
important one... does it seem useful for a lot of people?
On Fri, Mar 20, 2015 at 1:05 PM, Martin S. Weber <ephae...@gmx.net> wrote:
> On 2015-03-20 13:04:44, Richard Hipp wrote:
> > (...)
> > The way I deal with this in SQLite is:
> >
> > (1) Make logically separate changes in separate check-outs so that
> > they are easy to test and commit separately. (...)
>
> That's the sort of flow-interrupting context switch I was referring to
> on one hand, for myself; I see the usefulness of this approach, also it's
> very KISS. I like it. I usually do not treat checkouts as transient as
> this implies, but there's nothing wrong with doing that, considered it
> does not interrupt you. Maybe having it in mind won't interrupt me next
> time I stumble over it, I'll wait and see.
>
> > (2) On the occasions when I mess up and accidentally put (...)
>
> That's the sort of thing that one can do after the fact, i.e., when
> the housekeeping portion after the productivity burst is coming to
> take a breather... see more below.
>
> > (3) You might also check-in the whole thing into a side branch, then
> > do multiple partial merges back into the branch you were (...)
>
> I can see one doing this when they approach their checkout with a
> plan they know will create mess. It's good advice.
>
> I think in combination, your three approaches actually cover the use-cases
> I have, when I'm considering the topic of partial commits. I suppose the
> process of (2) and a partial commit selection would be actually end up
> being quite similar (in (2) you have more (visual) context but you make
> the same choices for the most part, i.e., select this, ignore that, ...)
>
> Partial commits would offer a line of "defense", of cleaning up and
> associating metadata with changes. (2) fulfills this role just as well.
> (1) is good reminder/advice for when the opening is quick. People
> should be doing (3) for messy stuff anyways :)
>
> > Still, there will always be people who are convinced that there is
> > nothing that can go wrong and what to do a partial commit against
> > expert advise.
>
> I wanted to showcase the potential usefulness of the feature. You're
> saying you got me covered already. After some consideration I think
> I agree. So no need for me to ask for and rely on yet-unwritten code.
>
> Thanks,
>
> -Martin
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
