[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gEDA-dev: Merge logjam - some attempt at mapping the conflict
Hi,
I've just a long time looking at the logjam using the 3-way gui diff
tool, "Meld". Attached is a text file with some of my notes.
(http://meld.sourceforge.net/) It is very handy!
Patrick's changes are _very_ extensive. It is like the diff of a huge
development series rolled into one. Their appear to be dialog
refactorings, code cleanup, general refactoring and re-writing - as well
as tackling the problem regarding moving.
(I'll confess to not being able to pick those changes out)
I have looked at the diff between the following sources:
Patrick's diffs - applied against CVS HEAD
Carlos's noscreen branch - when I copied it to start my work
My noscreen work
Highlighted below is where a 3-way merge will cause conflict, although
some functions might not be too bad, and many are similar. It does not
imply IN THE SLIGHTEST that the code will work when the other changes
are bought in though.
I'm looking at this from a viewpoint of applying my noscreen work ONTO
Patrick's codebase - thereby pushing more of the re-write load onto ME.
(I'm not too happy about that, but I'm willing to keep working on my
changes however the logjam gets broken).
I will make this note: Due to the vastness of Patrick's changes, it will
take MONTHS to merge in any sensible, incremental and tested way. (Even
if he has individual and incremental commits / patches in his own
revision control).
We'd need to do it in a branch of CVS, have people testing the changes.
etc.. In the mean time, further development work (noscreen and
potentially other far-reaching changes) would have to stop.
I don't think it is really fair to pause development for that long given
the unannounced nature of the change set, in the mean time destroying or
breaking other people's hard work as their patches become redundant or
stale. (I think of Carlos and myself here).
There is some good re-factoring in Patrick's work, but in my opinion, in
the process of breaking it down into sensible pieces, it may as well be
re-based on top of a Carlos's work, or even some of the noscreen
changes. (Which I've been using stably for some time now).
When moving to CVS with the noscreen work, I intend to re-work my
patches a little to ensure their quality. Perhaps Patrick and I could
get together and work on compatible, related and incremental changes /
re-factoring? We would both be sharing the burden of adapting and
re-basing our code then.
Patrick.. I hope I haven't been too harsh on you. I think your changes
are good, but surely you must see how difficult it would be to simply
merge them into CVS in one hit?
Regards,
Peter C.
Hi,
I've just spent several hours looking at the logjam using the 3-way gui diff tool, "Meld"
(http://meld.sourceforge.net/) It is very handy!
Patricks changes are _very_ extensive. It is like the diff of a huge development series rolled into one. Their appear to be dialog refactorings, code cleanup, general refactoring, re-writing as well as tackling the problem regarding moving.
I have looked at the diff between the following sources:
Patrick's diffs - applied against CVS HEAD
Carlos's noscreen branch - when I copied it to start my work
My noscreen work
Highlighted below is where a 3-way merge will cause conflict, although some might not be too bad. It doesn not imply IN THE SLIGHTEST that the code will work when the other changes are bought in. (I haven't read any of the new chunks of Patrick's code in detail). It is entirely possible that this needs converting to noscreen, and/or to remove / add recalcs as appropriate.
I'm looking at this from a viewpoint of applying my noscreen work ONTO Patrick's codebase, however due to the vastness of his changes, it will take MONTHS to merge in any sensible and incremental way. I don't think it is fair to pause development for that long given the un-announced nature of the changeset.
There is some good refactoring in Patrick's work, but in the process of breaking it down into sensible pieces, it may as well be rebased on top of a Carlos's work, or even some of the noscreen changes. (Which I've been using for some time now).
GSCHEM - the biggest nightmare
------------------------------
g_hook.c
custom_world_get_complex_bounds (check it fits in ok with noscreen work)
i_callbacks.c
edit_rotate_90_hotkey | PB new functions are much neater
edit_mirror_hotkey | - just add noscreen +/- recalc cache to this
o_arc.c
o_arc_draw
o_arc_draw_xor
o_basic.c
o_redraw_all | PB re-implemented... redo noscreen on top and remove unneeded recalcs
o_redraw_all_fast |
o_draw_bounding | Removed in PB
o_erase_bounding |
o_box.c
o_box_draw
o_box_draw_xor
o_buffer.c
o_buffer_copy
o_bus.c
o_bus_draw_xor
o_bus_draw_xor_stretched - new in PB - apply noscreen
o_circle.c
o_circle_draw
o_circle_draw_xor
o_complex.c
o_complex_draw
o_complex_erase
o_complex_place_start | New in PB
o_complex_place_end | Add noscreen and +/- recalcs as needed
o_complex_place_cancel |
o_complex_draw_xor | PB Removed
o_complex_start |
o_complex_end |
o_complex_translate_display_single_object |
o_complex_translate_display_object_glist |
o_complex_translate_display |
o_complex_translate2 |
o_complex_translate_all | Merge pain
vs. | Redo noscreen +/- recalcs as needed?
o_complex_move_to |
o_find.c
o_find_selected_object
o_line.c
o_line_draw
o_line_draw_xor
o_misc.c
o_embed (might just be whitespace)
o_move.c
o_move_start - Add noscreen +/- recalcs as needed
o_move_end_rubberband | PB Removed
o_move_stretch_rubberband |
o_net.c
o_net_draw_xor | Add noscreen +/- recalcs as needed
o_net_redraw_stretched |
o_picture.c
o_picture_draw_xor
o_pin.c
o_pin_draw_xor
o_text.c
o_text_draw_lowlevel
o_text_draw_rectangle - mine is much cleaner, uses cached bounds for the rectangle
o_text_draw_xor
o_text_place_rotate - PB Removed
x_event.c
x_event_button_released - Add noscreen +/- recalcs as needed to section PB re-did
LIBGEDA
-------
o_basic.c
o_recalc - needs a few fixes to PB's to reflect my removal of o_bus_recalc, o_net_recalc & o_pin_recalc
o_object_recalc - ????? (I removed it in mine, as there is no code where I need to re-calc an arbitrary object.
Each object is updated by its own code when moved / created in the noscreen branch)
o_complex_basic.c .... THE NIGHTMARE (so much merge conflict it is hard to know where to start!)
get_complex_bounds ??
(world_)get_single_object_bounds ??
(world_)get_object_list_bounds ??
o_complex_translate ??
o_complex_world_translate ??
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev