20 hours of my life I'm not getting back... not sure whether it's useful or not but I've been building up the infrastructure to let users browse the commit history of their version control system. For now, It only works properly with git and is very bare boned.
Apply the attached path to C::B sources, build C::B + file manager plugin and run C::B. Flip to the "files" tab, enable git decorators (right click on an item in the tab then look under settings in the popup):
(http://i.imgur.com/UChVfsQ.png)
Then navigate to a folder that's under Git version control. That will show a wxChoice box, click it and choose "Select Commit"
(http://i.imgur.com/xkIDolp.png)
Which will let you browse your commits.
(http://i.imgur.com/VGGpocA.png)
Select one and click on the "Use Selected Commit" button and you should be able to browse the tree for that commit and open the files in C::B (they are saved to a temp folder)
Obviously still needs a ton of work and has a bunch of silly bugs. The intent is to be able to support browsing of GIT, SVN, HG and BZR (and hopefully then you'll all see how shitty SVN is and we can switch to GIT!!) and do nice things like search and diff views.
See last post for the current patch.
cool, please also add support for svn ;-)
New patch attached supporting both GIT and SVN. This one updates the windows project file (but not the wx3.0 files) but hasn't been tested. GIT/SVN must be in the system path for the feature to work correctly.
Quote from: dmoore on January 31, 2015, 05:21:56 AM
New patch attached supporting both GIT and SVN.
Very nice... :D
New patch. Crushes a bunch of bugs and implements browsing for Bazaar and Mercurial. Plan to add support for searching commits by name or revision, viewing diffs etc.
But more generally, having now played around with a few different VCS systems, I think I can see how to integrate support for all of them throughout C::B. So, for example, when you have a file open in an editor that's under a VCS, you will be able to see options to see its VCS status, history, and diffs. The same goes for files in the project tree.
New patch features searching for a particular commit. (Date ranges don't work properly yet.)
EDIT: Ooops. bad patch. new one cominng soon.
Quote from: dmoore on February 09, 2015, 04:49:39 AM
New patch features searching for a particular commit. (Date ranges don't work properly yet.)
Does it make sense to move this functionality to the project tree sooner or later?
What do you mean by:
Quote from: dmoore on February 02, 2015, 03:33:36 AM
But more generally, having now played around with a few different VCS systems, I think I can see how to integrate support for all of them throughout C::B.
?
Does it mean another plugin / the work you do... something else? :-)
Quote from: MortenMacFly on February 09, 2015, 08:41:37 AM
Does it make sense to move this functionality to the project tree sooner or later?
Yes. It's reasonably stable now, so as soon as I can. But still need to test on windows and fix the makefiles.
Quote
Does it mean another plugin / the work you do... something else? :-)
Not sure yet. Maybe just a separate VCS plugin, but that will be a little tricky to integrate with a separate file manager plugin. Otherwise a new manager/plugin combination, but I'd prefer not to do that. It will mean refactoring this patch quite a bit to separate out VCS specific code into separate classes.
Updated patch attached.
Now in SVN (http://sourceforge.net/p/codeblocks/code/10107/). I think I got the makefiles and windows stuff right, but not wx3.0 yet, and probably not PCH/non-PCH.
works nicely.
Some requests ? suggestions ? (doing this via svn)
- can a history entry be made (now it is available, via the diff against)
- but the diff, when you get it via right click context menu is containing all commits, would be more nice to have only the commits impacting this file
- in the history (diff), select 2 revisions and see the diff between those 2
- some way of instructing that the diff should be send to meld (instead of the patch diff notation)
Is there a way when in the project tree to end up directly to the integration which is now in the Files tab ? Or as step in between : right click on a file in the project tree, and tell it to go to the corresponding place in the files tree (so no need to search there for the file first) ?
Quote from: killerbot on February 11, 2015, 10:48:24 AM
Some requests ? suggestions ? (doing this via svn)
Of course. SVN is the problem child. For example, I still need to figure out how to handle password prompts every time I browse the log ???
Quote
- can a history entry be made (now it is available, via the diff against)
As in the history of commits? Not sure what you have in mind.
Quote
- but the diff, when you get it via right click context menu is containing all commits, would be more nice to have only the commits impacting this file
Yes, planning to add the feature to specify changes only affecting a certain file in the commit browser dialog and to use that by default for the diff.
Quote
- in the history (diff), select 2 revisions and see the diff between those 2
- some way of instructing that the diff should be send to meld (instead of the patch diff notation)
Yes, eventually
Quote
Is there a way when in the project tree to end up directly to the integration which is now in the Files tab ? Or as step in between : right click on a file in the project tree, and tell it to go to the corresponding place in the files tree (so no need to search there for the file first) ?
I do plan to integrate something into the project tree, but not sure how extensive that will be just yet. Right now you can right click on a project and open the corresponding directory in the file browser and I could probably do something similar for individual files. The logic is trickier if the repo is say, /projects, the project file is as project/project1/project1.cbp, but the file is /project1/src/module1/module1.cpp. Should the filemanager set the root to /projects and then expand the subdirectories to show and center on the location of the file? The logic for that is a little tricky because you need to figure out which repo the file is in.
By the way, the show changed files only also makes it easier to find changed files.
My 2 cents for today...:
1.) I don't understand the "favourites" system: I can setup favourites (that works nice), but how do I access them?
2.) Crash: Whenever I try to set some folder to be the root folder I get a crash pointing to the FileManager plugin.
Quote from: MortenMacFly on February 11, 2015, 05:45:51 PM
2.) Crash: Whenever I try to set some folder to be the root folder I get a crash pointing to the FileManager plugin.
Some more details:
It happens in the marked line:
Updater::~Updater()
{
if(m_exec_proc)
{
m_exec_timer->Stop(); // << crash here!
delete m_exec_timer;
m_exec_proc->Detach();
m_exec_cond->Signal();
m_exec_mutex->Unlock();
}
if(IsRunning())
{
m_kill=true;
Wait();
}
}
...and
m_exec_timer is "0xbaadf00d" -> unallocated.
It happens on folders that are under version control and where the VCS executables are not found (in the debug build I see: "Execution of command XXXX failed...").
Quote from: MortenMacFly on February 11, 2015, 05:50:53 PM
...and m_exec_timer is "0xbaadf00d" -> unallocated.
Naaah... fixed in SVN.
You'd better remember to ALWAYS initialise pointer variables in the constructor in the future... ;-)
Quote from: MortenMacFly on February 11, 2015, 05:58:09 PM
Naaah... fixed in SVN.
...but I'll give you another one: If in debug mode, a missing VCS executable will raise a wxExecute error dialog that freezes C::B completely.
My suggestion:
If you handle the wxExecute result yourself (which seems to be the case), use wxLogNull to avoid such freezes, like:
{
wxLogNull ln;
h_result = wxExecute(...)
}
To handle all the different wxExecute calls across the plugin (I counted at least 15) you should put them into one place/method which you call with a parameter what command to call exactly.
Maybe you share my thoughts...?!
Quote from: MortenMacFly on February 11, 2015, 05:45:51 PM
My 2 cents for today...:
1.) I don't understand the "favourites" system: I can setup favourites (that works nice), but how do I access them?
The first items in the ComboBox that shows the current path will be populated with your favorites. (It's a little clunky, I admit.)
Quote from: MortenMacFly on February 11, 2015, 05:58:09 PM
Quote from: MortenMacFly on February 11, 2015, 05:50:53 PM
...and m_exec_timer is "0xbaadf00d" -> unallocated.
Naaah... fixed in SVN.
You'd better remember to ALWAYS initialise pointer variables in the constructor in the future... ;-)
Well, that's embarrassing.
Quote from: MortenMacFly on February 11, 2015, 06:20:09 PM
...but I'll give you another one: If in debug mode, a missing VCS executable will raise a wxExecute error dialog that freezes C::B completely.
Thanks for the tip. I had already refactored all of the wxExecute calls into a single place for the threaded parts and will do the same for the remaining calls.
Quote from: dmoore on February 11, 2015, 07:05:40 PM
The first items in the ComboBox that shows the current path will be populated with your favorites. (It's a little clunky, I admit.)
Aaah - dammed - I missed it. :-/ But if you know it makes sense. Maybe a "hint" like a label would help to discover...
Hi, nice idea but...the recent svn-changes are breaking my build :-(
I use Ubuntu 14.04 and compile the trunk via makefile quite regularly. That stopped 3 days ago.
It looks like this bug has been introduced by svn 10107 since I have a working 10106.
Compiling cb stops with:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../../../trunk/src/plugins/contrib/FileManager -I../../../../src/include -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../trunk/src/include -I../../../../../trunk/src/sdk/wxscintilla/include -I../../../../../trunk/src/include/mozilla_chardet -I../../../../../trunk/src/include/mozilla_chardet/mfbt -I../../../../../trunk/src/include/mozilla_chardet/nsprpub/pr/include -I../../../../../trunk/src/include/mozilla_chardet/xpcom -I../../../../../trunk/src/include/mozilla_chardet/xpcom/base -I../../../../../trunk/src/include/mozilla_chardet/xpcom/glue -ansi -DTIXML_USE_STL -Wno-unused-local-typedefs -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -D__FAM__ -MT FileExplorerUpdater.lo -MD -MP -MF .deps/FileExplorerUpdater.Tpo -c ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp -fPIC -DPIC -o .libs/FileExplorerUpdater.o
In file included from ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp:9:0:
../../../../../trunk/src/plugins/contrib/FileManager/se_globals.h:10:17: fatal error: ../../../../src/include/sdk.h: No such file or directory
#include <sdk.h>
^
compilation terminated.
Preprocessed source stored into /tmp/ccirly8F.out file, please attach this to your bugreport.
make[4]: *** [FileExplorerUpdater.lo] Error 1
The file sdk.h exists in:
codeblocks/trunk/src/plugins/contrib/FileManager$ ls -l ../../../include/sdk.h
-rw-r--r-- 1 user user 457 Apr 2 2013 ../../../include/sdk.h
I always build cb in a directory named build that is parallel to the trunk directory. The plugins up to FileManager compile and the
file sdk.h.gch has been written as usual.
Can you fix this, please? Thank you!
Btw: A cppcheck over the plugin files yields several issues. A few of those might be of a help:
cppcheck --verbose --enable=all *.h *.cpp
[FileExplorerUpdater.h:44]: (warning) Member variable 'Updater::m_exec_cond' is not initialized in the constructor.
Is there a reason why you put initializations, if any, into the body instead of the initializer list?
[FileExplorerUpdater.cpp:1410]: (error) Uninitialized variable: hg_not_done
bool hg_not_done;
if (m_repo_type == _T("Hg"))
{
long last;
if (m_last_commit_retrieved.ToLong(&last))
if (last > 0)
hg_not_done = true;
}
if (hg_not_done)
m_retrieved_all = false;
This is definitely undefined behaviour.
[FileExplorer.cpp:1340] -> [FileExplorer.cpp:1340]: (style) Finding
the same expression on both sides of an operator
is suspicious and might indicate a cut and paste
or logic error. Please examine this code carefully to determine if it is correct.
if(!wxFileName::DirExists(mkd) &&!wxFileName::DirExists(mkd))
To me this looks being unintended.
[directorymonitor.cpp:621]: (warning) Possible leak in public function.
The pointer 'm_monitorthread' is not deallocated before it is allocated.
bool wxDirectoryMonitor::Start()
{
m_monitorthread=new DirMonitorThread(this, m_uri, false, false, m_eventfilter, 100);
m_monitorthread->Create();
m_monitorthread->Run();
return true;
}
Since Start is a public method, and m_monitorthread is a naked pointer this is not safe.
Thanks!
Thanks for all of the fixes. A few oopses in there :) :-[
Maybe I'm being dense but I'm not sure what the problem here is
Quote from: blauzahn on February 12, 2015, 10:21:35 PM
I use Ubuntu 14.04 and compile the trunk via makefile quite regularly. That stopped 3 days ago.
It looks like this bug has been introduced by svn 10107 since I have a working 10106.
Compiling cb stops with:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../../../trunk/src/plugins/contrib/FileManager -I../../../../src/include -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../trunk/src/include -I../../../../../trunk/src/sdk/wxscintilla/include -I../../../../../trunk/src/include/mozilla_chardet -I../../../../../trunk/src/include/mozilla_chardet/mfbt -I../../../../../trunk/src/include/mozilla_chardet/nsprpub/pr/include -I../../../../../trunk/src/include/mozilla_chardet/xpcom -I../../../../../trunk/src/include/mozilla_chardet/xpcom/base -I../../../../../trunk/src/include/mozilla_chardet/xpcom/glue -ansi -DTIXML_USE_STL -Wno-unused-local-typedefs -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -D__FAM__ -MT FileExplorerUpdater.lo -MD -MP -MF .deps/FileExplorerUpdater.Tpo -c ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp -fPIC -DPIC -o .libs/FileExplorerUpdater.o
In file included from ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp:9:0:
../../../../../trunk/src/plugins/contrib/FileManager/se_globals.h:10:17: fatal error: ../../../../src/include/sdk.h: No such file or directory
#include <sdk.h>
^
compilation terminated.
Preprocessed source stored into /tmp/ccirly8F.out file, please attach this to your bugreport.
make[4]: *** [FileExplorerUpdater.lo] Error 1
The file sdk.h exists in:
codeblocks/trunk/src/plugins/contrib/FileManager$ ls -l ../../../include/sdk.h
-rw-r--r-- 1 user user 457 Apr 2 2013 ../../../include/sdk.h
I always build cb in a directory named build that is parallel to the trunk directory. The plugins up to FileManager compile and the
file sdk.h.gch has been written as usual.
Comparing the makefiles, it's really not obvious to me what's different.
And looking at the makefile diff, I struggle to see how anything changed there can be the cause:
http://sourceforge.net/p/codeblocks/code/10107/tree//trunk/src/plugins/contrib/FileManager/Makefile.am?diff=51421f1dc431436b6eb31d56:10106
Are you sure there isn't some sort of corruption of the FileManager sources?
Quote
Are you sure there isn't some sort of corruption of the FileManager sources?
Yes I am. I downloaded a fresh, vanilla trunk into a newly created empty directory. Same result.
mkdir tmp
cd tmp
svn checkout svn://svn.code.sf.net/p/codeblocks/code/trunk
cd trunk
./bootstrap
cd ..
mkdir build
cd build
../trunk/configure --prefix=/usr/local --with-contrib-plugins=all,-NassiShneiderman
make
I do not see either a thing within the Makefile.am diff that may have caused that. What else?
If I skip the FileManager, the code compiles cleanly:
../trunk/configure --prefix=/usr/local --with-contrib-plugins=all,-NassiShneiderman,-FileManager
make -j
The breaking change might also be introduced by a version higher than 10107. Haven't bisected it yet.
I confirm the breakage. It happens in out-of-tree builds and only if using pch. If I specify --disable-pch it builds fine.
I have no issues building actual trunk (10118) out of tree, neither with pch, nor without pch.
Probably it is something related to newer autotools, because it worked correctly on my CentOS 6 machine, but failed on my Gentoo machine.
It tested it on my Fedora 21 system and did a build in mock chroots for CentOS 5 to 7 and Fedora 19 to Rawhide (22) (sse: https://copr.fedoraproject.org/coprs/jenslody/codeblocks/build/71814/ (https://copr.fedoraproject.org/coprs/jenslody/codeblocks/build/71814/)).
For the record: the copr-builds are all build without pch's and not out of tree.
I solved the problem I had compiling the plugin starting exactly from version r10107 upwards.
If I change the include-order it works. I changed the first lines of FileExplorerUpdater.cpp from:
#include <sdk.h>
#include <wx/sstream.h>
#include <wx/regex.h>
#include <set>
#include "FileExplorerUpdater.h"
#include "FileExplorer.h"
#include "se_globals.h"
to:
#include "FileExplorerUpdater.h"
#include "FileExplorer.h"
#include "se_globals.h"
#include <sdk.h>
#include <wx/sstream.h>
#include <wx/regex.h>
#include <set>
The main point is to move sdk.h downwards. This should be fixed in trunk. Thanks!
And another point, where the dependency can be reduced: in FileManager.h there is no need to include FileExplorer.h. Instead
a forward declaration is sufficient. The include can be moved into FileManager.cpp instead.
IMHO, the include order should follow advices of:
* Herb Sutter (C++ Coding Standards §22: "Minimize definional dependencies.[...]",
* Herb Sutter (C++ Coding Standards §23: "Make header files self-sufficient" and
* John Lakos (Large Scale C++ Software Design: Major Design Rule "The .c[pp] file of every component should include
its own .h file as the first substantial line of code."
Therefore, I personally would prefer the #include order.
own header
plugin
cb
wx
std
The interference with pre-compiled header is another story.
Quote from: blauzahn on February 21, 2015, 08:24:58 AM
IMHO, the include order should follow advices of:
* Herb Sutter (C++ Coding Standards §22: "Minimize definional dependencies.[...]",
* Herb Sutter (C++ Coding Standards §23: "Make header files self-sufficient" and
* John Lakos (Large Scale C++ Software Design: Major Design Rule "The .c[pp] file of every component should include
its own .h file as the first substantial line of code."
Therefore, I personally would prefer the #include order.
own header
plugin
cb
wx
std
The interference with pre-compiled header is another story.
I prefer this order
PCH
std
wx
cb
own header
Last time I checked this header had issues "se_globals.h" so moving it till just below sdk.h might be needed till the issues are fixed.
When I have time I will see if I can submit a patch on the headers in FileManager CB Plugin.
Tim S.
Quick patch that needs more testing.
https://github.com/stahta01/cb_misc/blob/master/Patches/svn/cb_PCH_FileManager.patch (https://github.com/stahta01/cb_misc/blob/master/Patches/svn/cb_PCH_FileManager.patch)
Builds on Windows 7 64 Bit using 32 bit TDM GCC.
Tested both wx30 and wx28 builds.
Yes, I have finally confirmed that GCC on Linux acts like MinGW GCC and needs an include to the object folder to work.
Tested on Debian Wheezy 64 bit (wx28) it took about 30+ seconds to build without patch about 15 seconds with patch.
(The patch includes both the one linked above and the one in the code below).
Index: src/plugins/contrib/FileManager/FileManager-unix.cbp
===================================================================
--- src/plugins/contrib/FileManager/FileManager-unix.cbp (revision 10123)
+++ src/plugins/contrib/FileManager/FileManager-unix.cbp (working copy)
@@ -44,6 +44,7 @@
<Add option="-DcbDEBUG" />
<Add option="-DCB_PRECOMP" />
<Add option="-D__FAM__" />
+ <Add directory="../../../.objs/include" />
<Add directory="../../../include" />
<Add directory="../../../sdk/wxscintilla/include" />
<Add directory="../../../include/mozilla_chardet" />
Edit2: I plan to test Debian wxWidgets 3.0 branch once I get it built. My Internet connection is very slow today so it might be a while before I get the git checkout done.
Tim S.