Showing patches in "About Inkscape"
Would anybody else find it helpful if "about inkscape" showed a list of all the patches that were applied? Not the ones that were committed to trunk, but the ones that are still in play, so to speak. At any given time I have several that have been submitted but have not yet been checked on OSX and then committed. Or they fell through the cracks for some other reason and were never committed, or have not yet been posted. The mixture that are present in any given build may vary, and diffing the patch files to see what is what is not fun.
That said, I'm not at all sure how one would coerce bzr and patch to allow this. Presumably there would be a "patches.cpp" containing text something like:
... "this patch", "that patch", ...
and each patch would stick a name in there to identify itself. Before commit, just remove the patch specific for "patches.cpp". I suspect patch might get awfully confused by that file. It would probably be easier to apply the patches through a script so that:
./apply_patch.sh for_this.patch
would take the file name and automagically edit it into the file, while dropping the "bzr diff" generated path TO "patches.cpp".
Just a thought,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
2014-04-11 2:15 GMT+02:00 mathog <mathog@...1176...>:
Would anybody else find it helpful if "about inkscape" showed a list of all the patches that were applied? Not the ones that were committed to trunk, but the ones that are still in play, so to speak.
Right now there is some Automake code that appends "custom" to the version string if you have any modifications with respect to the checked-out revision.
At any given time I have several that have been submitted but have not yet been checked on OSX and then committed. Or they fell through the cracks for some other reason and were never committed, or have not yet been posted. The mixture that are present in any given build may vary, and diffing the patch files to see what is what is not fun.
If you are running into this problem, I think you would be better off maintaining a few branches that collect related changes. You can then post them for review on Launchpad. It's not 1990 anymore, we have reasonable source control tools now.
Another option may be Quilt, though I haven't worked with it. http://en.wikipedia.org/wiki/Quilt_%28software%29
That said, I'm not at all sure how one would coerce bzr and patch to allow this. Presumably there would be a "patches.cpp" containing text something like:
... "this patch", "that patch", ...and each patch would stick a name in there to identify itself. Before commit, just remove the patch specific for "patches.cpp". I suspect patch might get awfully confused by that file. It would probably be easier to apply the patches through a script so that:
./apply_patch.sh for_this.patch
would take the file name and automagically edit it into the file, while dropping the "bzr diff" generated path TO "patches.cpp".
This is a very complex solution for a problem I think approximately nobody else haves. However, if there is some demand, I can implement something like that (probably using Quilt), but not before we move the build system to Waf. Doing something like that in Automake is going to be painful.
Regards, Krzysztof
Quilt is quite a nice solution. I had briefly thought about using it to maintain our "official" changes to upstream code (gimp widgets, libcroco etc). We'd just need to have a file containing a list of the desired patches and then add a rule to the makefile that calls quilt on that list. The contents of the patch list file could easily be added to the About dialog.
AV On 11 Apr 2014 07:43, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
2014-04-11 2:15 GMT+02:00 mathog <mathog@...1176...>:
Would anybody else find it helpful if "about inkscape" showed a list of all the patches that were applied? Not the ones that were committed to trunk, but the ones that are still in play, so to speak.
Right now there is some Automake code that appends "custom" to the version string if you have any modifications with respect to the checked-out revision.
At any given time I have several that have been submitted but have not yet been checked on OSX and then committed. Or they fell through the cracks for some other reason and were never committed, or have not yet been posted. The mixture that are present in any given build may vary, and diffing the patch files to see what is what is not fun.
If you are running into this problem, I think you would be better off maintaining a few branches that collect related changes. You can then post them for review on Launchpad. It's not 1990 anymore, we have reasonable source control tools now.
Another option may be Quilt, though I haven't worked with it. http://en.wikipedia.org/wiki/Quilt_%28software%29
That said, I'm not at all sure how one would coerce bzr and patch to allow this. Presumably there would be a "patches.cpp" containing text something like:
... "this patch", "that patch", ...and each patch would stick a name in there to identify itself. Before commit, just remove the patch specific for "patches.cpp". I suspect patch might get awfully confused by that file. It would probably be easier to apply the patches through a script so that:
./apply_patch.sh for_this.patch
would take the file name and automagically edit it into the file, while dropping the "bzr diff" generated path TO "patches.cpp".
This is a very complex solution for a problem I think approximately nobody else haves. However, if there is some demand, I can implement something like that (probably using Quilt), but not before we move the build system to Waf. Doing something like that in Automake is going to be painful.
Regards, Krzysztof
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (3)
-
Alex Valavanis -
Krzysztof Kosiński -
mathog