On Wed, May 23, 2018 at 4:28 PM, Jürgen E. Fischer <[email protected]> wrote:
> Hi Vittorio, > > On Wed, 23. May 2018 at 15:31:44 +0200, Vittorio Carlo Alfieri wrote: > > While these changes are good, unfortunately, (for me at least), all these > > I humbly request, if available and not available online somewhere, a copy > > of the git repository used to develop libdxfrw up to the point where it > was > > introduced in Qgis in 2016 so that I may continue to bisect the code and > > find the fix for the DWG that I can't open outside of Qgis. > > You're looking for https://github.com/jef-n/QGIS/commits/dwg-import ? > Wow, yes! Exactly this. I can now continue digging around for the fix. Thanks! > > > > P.S. If the original git repository is still available it would be great > if > > placed on Github and possibly even used as a submodule within qgis itself > > so as to have the same git tree as upstream for libdxfrw. This would > > greatly increase harmonization of source code between the various forks > of > > libdxfrw and de-duplicate much effort for all parties! I would be willing > > to help implement this for you guys if so desired. > > Isn't libdxfrw dead? > > https://sourceforge.net/p/libdxfrw/code/ci/65177975f7999fc37 > 5813bb50b463554f7395d08/ > > is what I started from and it's still the latest commit... > Yeah, I also noticed this. While the Sourceforge repo appears dead, there has been recent development for libdxfrw at the following git source trees (amongst others): https://github.com/rvt/libdxfrw/commits/master https://github.com/LibreCAD/LibreCAD/commits/master/libraries/libdxfrw/src Please note: I am not a member of the LibreCAD team, I am just trying to fix a bug upstream that is affecting me, and noticed that you had fixed it! Congratulations on your hard work. Personally, I would choose https://github.com/rvt/libdxfrw as the "upstream" for this library, for the following reasons: 1. It contains the entire git source tree, including initial development from Rallaz, the original creator of libdxfrw and one of the lead developers of LibreCAD 2. 2. It is already used as a submodule in the upcoming LibreCAD 3. 3. Without too much work from the LibreCAD team it can also be used as a submodule in LibreCAD 2. 4. It is on Github instead of Sourceforge. 5. It seems to be condoned by Rallaz himself, because the developer, RVT, is also an administrator of the SourceForge repo and a member of the LibreCAD team on Github. In the end it doesn't really matter which git upstream is chosen for the library, as long as the object ID of the first commit is the same as the original Sourceforge version. This tells git that we are talking about the same source tree. This is not the case in the current Qgis source tree since libdxfrw was "forked" from the Qgis source tree. In my mind, ideally the Qgis project would clone/fork this library, rebase the Qgis specific modifications onto the latest upstream version and perform pull-requests for non qgis-specific fixes. After this fork is successfully created, it could then be integrated by the Qgis team as a git submodule in order to permit merging and re-basing between the various forks of the libdxfrw project independently from the Qgis development. If this is interesting to you, before performing any changes, I would consult LibreCAD team to make sure I'm not way off-base and wrong. I would be willing to help, if so desired, with any of the following: 1. Contacting the LibreCAD team to see if rvt/libdxfrw is going to be their upstream going forward. 2. Rebase your modifications of libdxfrw onto rvt/libdxfrw source tree and create the qgis/libdxfrw fork. 3. Try to upstream whatever commit fixes the bug that is affecting me. Regardless, thank you for the prompt and helpful response, Vittorio Alfieri
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
