Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: dmoore on January 30, 2015, 04:30:27 am

Title: FileManager: Version Control Browsing
Post by: dmoore on January 30, 2015, 04:30:27 am
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.
Title: Re: FileManager: Version Control Browsing
Post by: killerbot on January 30, 2015, 07:24:51 am
cool, please also add support for svn ;-)
Title: Re: FileManager: Version Control Browsing
Post by: dmoore on January 31, 2015, 05:21:56 am
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.
Title: Re: FileManager: Version Control Browsing
Post by: MortenMacFly on January 31, 2015, 07:04:21 am
New patch attached supporting both GIT and SVN.
Very nice... :D
Title: Re: FileManager: Version Control Browsing
Post by: dmoore on February 02, 2015, 03:33:36 am
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.
Title: Re: FileManager: Version Control Browsing
Post by: dmoore on February 09, 2015, 04:49:39 am
New patch features searching for a particular commit. (Date ranges don't work properly yet.)

EDIT: Ooops. bad patch. new one cominng soon.
Title: Re: FileManager: Version Control Browsing
Post by: MortenMacFly on February 09, 2015, 08:41:37 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:
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? :-)
Title: Re: FileManager: Version Control Browsing
Post by: dmoore on February 09, 2015, 04:23:42 pm
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.
Title: Re: FileManager: Version Control Browsing
Post by: dmoore on February 10, 2015, 05:34:58 am
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.

Title: Re: FileManager: Version Control Browsing
Post by: killerbot on February 11, 2015, 10:48:24 am
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) ?
Title: Re: FileManager: Version Control Browsing
Post by: dmoore on February 11, 2015, 02:58:19 pm
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.
Title: Re: FileManager: Version Control Browsing
Post by: 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?
2.) Crash: Whenever I try to set some folder to be the root folder I get a crash pointing to the FileManager plugin.
Title: Re: FileManager: Version Control Browsing
Post by: MortenMacFly on February 11, 2015, 05:50:53 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...").
Title: Re: FileManager: Version Control Browsing
Post by: MortenMacFly on February 11, 2015, 05:58:09 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... ;-)
Title: Re: FileManager: Version Control Browsing
Post by: MortenMacFly on February 11, 2015, 06:20: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...?!
Title: Re: FileManager: Version Control Browsing
Post by: dmoore on February 11, 2015, 07:05:40 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.)

...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.

...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.
Title: Re: FileManager: Version Control Browsing
Post by: MortenMacFly on February 11, 2015, 08:56:54 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...
Title: Re: FileManager: Version Control Browsing
Post by: blauzahn on February 12, 2015, 10:21:35 pm
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:

Code
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:

Code
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:

Code
cppcheck --verbose --enable=all *.h *.cpp

Code
[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?

Code
[FileExplorerUpdater.cpp:1410]: (error) Uninitialized variable: hg_not_done

Code
  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.

Code
[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.

Code
 if(!wxFileName::DirExists(mkd) &&!wxFileName::DirExists(mkd))

To me this looks being unintended.

Code
[directorymonitor.cpp:621]: (warning) Possible leak in public function. 
  The pointer 'm_monitorthread' is not deallocated before it is allocated.

Code
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!

Title: Re: FileManager: Version Control Browsing
Post by: dmoore on February 12, 2015, 11:27:57 pm
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

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:

Code
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:

Code
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.
Title: Re: FileManager: Version Control Browsing
Post by: dmoore on February 12, 2015, 11:32:32 pm
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?
Title: Re: FileManager: Version Control Browsing
Post by: blauzahn on February 13, 2015, 06:46:21 am
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.

Code
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?
Title: Re: FileManager: Version Control Browsing
Post by: blauzahn on February 13, 2015, 07:00:01 am
If I skip the FileManager, the code compiles cleanly:

Code
 ../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.
Title: Re: FileManager: Version Control Browsing
Post by: oBFusCATed on February 13, 2015, 10:43:15 am
I confirm the breakage. It happens in out-of-tree builds and only if using pch. If I specify --disable-pch it builds fine.
Title: Re: FileManager: Version Control Browsing
Post by: Jenna on February 13, 2015, 01:08:13 pm
I have no issues building actual trunk (10118) out of tree, neither with pch, nor without pch.
Title: Re: FileManager: Version Control Browsing
Post by: oBFusCATed on February 13, 2015, 01:36:45 pm
Probably it is something related to newer autotools, because it worked correctly on my CentOS 6 machine, but failed on my Gentoo machine.
Title: Re: FileManager: Version Control Browsing
Post by: Jenna on February 13, 2015, 08:20:31 pm
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.
Title: Re: FileManager: Version Control Browsing
Post by: blauzahn on February 21, 2015, 08:24:58 am
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:

Code
#include <sdk.h>

#include <wx/sstream.h>
#include <wx/regex.h>
#include <set>

#include "FileExplorerUpdater.h"
#include "FileExplorer.h"
#include "se_globals.h"

to:

Code
#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.
Title: Re: FileManager: Version Control Browsing
Post by: stahta01 on February 21, 2015, 02:00:59 pm

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.





Title: Re: FileManager: Version Control Browsing
Post by: stahta01 on February 21, 2015, 04:56:28 pm
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).

Code
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.