sslater11 / tuxguitar-simons-build-scripts Goto Github PK

Hi @sslater11, and thanks for these tools
A "discussion" would probably be more appropriate than an "issue", but it seems discussions are not enabled in this repo.

I really like this idea to assist back-porting from one fork to another with scripts. However, from a practical point of view it's not that simple... let me just share my experience.
There are many, many commits in 2.0beta that I cannot build, even with these tools. Others build correctly but fail at startup. So, using git bisect in an efficient manner is quite a challenge.
A few examples:

• even last commit (84a2b766b0118225ac1004f485c189fa367dc20e) does not build! I get an error Unable to find artifact.: The following artifacts could not be resolved: org.herac.tuxguitar:tuxguitar-gtk-integration:jar:2.0-SNAPSHOT (absent). This can be bypassed by deleting <artifactId>tuxguitar-gtk-integration</artifactId> from pom.xml
• oldest common commits between forks (fb3c0035f4faccd83097e46a990bb589d2a1e7a5): Failed to read artifact descriptor for org.eclipse.swt:org.eclipse.swt.gtk.linux.x86_64:jar:4.6.1: The following artifacts could not be resolved: org.eclipse.swt:org.eclipse.swt.gtk.linux.x86_64:pom:4.6.1 (present, but unavailable). I don't understand this one... I have for sure downloaded and installed version 4.6.1. "present but unavailable" really puzzles me. I could not bypass this error.
• intermediate (09533d07a09a1610c38d851baec8dace2087f5dc): GTKTitleBar.java:[50,29] cannot find symbol: method gtk_header_bar_new(). This one is really annoying. In some commits it works after deleting tuxguitar-gtk-integration from pom file. Sometimes it builds without this dependency but crashes at startup.
• ... it's difficult to build an exhaustive list, there are many different errors

Furthermore, even simple features are often implemented in several successive steps (enhancements, bug fixes, etc), with significant distance between them. So I did not succeed to use your meld_merge tool as you suggested to assist the merge.
Just for information, my strategy is now this one:

• try to bisect approximately, to find an area of 10-20 commits where the new feature has been introduced. This step can be very time-consuming
• analyze (manually) all modifications implemented in this area. This can also take some time, because commit messages are sometimes very synthetic
• list a few modified files critical to the feature
• go back to most recent commit, and compare the few files in the most recent versions of the 2 forks
• at this stage, often the compared files are really too different to use meld in an efficient manner. Or I just don't master this tool! One difficult point is to pick only the requested evolution, not everything.

At least this gives an entry point. Then I follow all dependencies of new classes, methods, and so on using Eclipse IDE.
That's definitely not perfect, but this is finally the only practical approach that I could use (this is the way I merged the "click & drag select" feature).

Up to now, adaptations were always needed: either to keep compatibility with JFX, to avoid pulling all the new user interface with 1 single simple feature, or simply to correct some bugs.