On 31-01-13 17:15, John Ralls wrote:
On Jan 31, 2013, at 7:04 AM, Derek Atkins <[email protected]> wrote:
Geert Janssens <[email protected]> writes:
[snip]
Daggy fixing is probably not the only useful scheme though. I could
also imagine something like this to work:
- all bugfixes and only bugfixes happen on the 2.4 branch
- the 2.4 branch regularly gets merged into the development branch, so
all bugfixes also will end up in future releases
This concept is no longer back-porting, but
forward-porting. Advantage: all bugfixes eventually end up in the
active trees and git branches show the history, no need for BP->AUDIT
Note that neither daggy fixing nor forward porting are possible as
long as we're tied to svn. So this discussion is on future process,
not practical next steps yet.
Techncally we could do the "all bugfixes go into release; frequently
merge release back into trunk" method. The downside is that larger
"fixes" dont get tested as much before going into the release.
I think that you guys have a misunderstanding about how merging works.
Perhaps I do. That's why I'm discussing this topic here :)
Try merging 2.4 back into trunk.
When I did just now, 4 files merged successfully, the rest have conflicts. One
might be able to do better by playing with the merge options. I'm not going to
spend the time.
I believe this is in large part because the common ancestor between 2.4
and trunk is already too far down history. I explicitly said regularly
merging into the development branch.
Isn't it so that git's merge starts to compare differences from the most
recent common ancestor ? That would mean that if the bugfixes were
merged into development frequently (in the extreme case for each bugfix
commit) the merge conflicts would be no more complicated than you would
encounter with cherry-picking.
Merging a commit doesn't just look at the files touched by that particular
commit, it looks at every difference between the trees of the source commit and
the target (i.e., the current branch).
Cherry-pick exists for a reason.
Sure, but I'm not convinced yet that that reason is our use case here.
Suppose we depend on cherry picking for back- or forward-porting. How
can it help us not to forget any back- or forward ports without having
to go through all the commits manually to compare them between branches ?
Our current process (using the BP and AUDIT markers) has the same
weaknesses IMO. There is no clear indication in the commit history of
which commits were backported. We have BP/AUDIT as a visual reminder
that backports should happen, but no easy way to check in retrospect if
they actually happened.
How can we in the future improve our process to something in which the
history clearly reflects what actually happened, in which no work is
lost (by forgetting to backport) and without too much overhead.
And also test/review changes before they go into the release branch?
The generally accepted best practice for that is to require 100% test coverage
and to require that all tests (including a new one that covers the current
change) pass. It doesn't seem likely that we would adopt that practice.
No, we're not set up for that. But I believe it should be one of our
goals to get better test coverage. I know you have this on your agenda
and I'm quite happy about it.
A couple of times I started looking into writing tests myself, but never
managed to actually produce some due to lack of time and experience.
Perhaps this is a good time to ask:
a. do you know of a good introduction to unit testing ?
b. is there some documentation on the unit testing framework used in
gnucash ? How should a test be constructed ? Are there particular
functions that should be used ? Things like that.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
