1. 24 Jun, 2010 1 commit
  2. 31 May, 2010 1 commit
  3. 22 Apr, 2010 1 commit
  4. 06 Mar, 2010 3 commits
  5. 17 Feb, 2010 1 commit
  6. 16 Feb, 2010 1 commit
  7. 15 Feb, 2010 3 commits
  8. 17 Oct, 2009 1 commit
  9. 26 Jul, 2009 1 commit
  10. 22 Jul, 2009 1 commit
  11. 08 Jul, 2009 1 commit
  12. 07 Jul, 2009 1 commit
    • Ramon Zarazua's avatar
      Merging of Code refactoring branch.\n\nChanges include:\nChanged internal... · 6d7b84cd
      Ramon Zarazua authored
      Merging of Code refactoring branch.\n\nChanges include:\nChanged internal class generation structure to not depend on user input, and work as a generator.\nInitial implementation of Making C++ Implementation private, only works on very select occations.\nExtraction of some useful utilities that were bound inside simplerefactoring.cpp
      6d7b84cd
  13. 21 Jun, 2009 1 commit
  14. 20 Jun, 2009 1 commit
  15. 02 Jun, 2009 1 commit
  16. 22 May, 2009 1 commit
  17. 15 Apr, 2009 1 commit
  18. 06 Apr, 2009 1 commit
  19. 04 Apr, 2009 1 commit
  20. 02 Apr, 2009 1 commit
  21. 23 Mar, 2009 1 commit
  22. 15 Mar, 2009 1 commit
  23. 03 Oct, 2008 1 commit
    • Andreas Pakulat's avatar
      Provide aboutData information for the plugins. Its not much work to set this... · 4c56ce7f
      Andreas Pakulat authored
      Provide aboutData information for the plugins. Its not much work to set this up and it will (hopefully soon) allow a nice tree in the shortcuts editor just like in KDE3.
      
      Everybody who's code I touched should check wether the descriptions are right
      and the license is correct too (its all GPL I think, but better double-check).
      
      What I'm not sure about is wether we also want to add the authors, it would
      need a createAboutData function as you can't provide authors within the
      constructor. Opinions?
      
      If somebody feels he's up for some non-thinking work, feel free to actually
      copy the description from the .desktop files. It would be nice to have .desktop
      and aboutData information in sync, but I'm not going to require that as its a
      pretty tedious job that doesn't buy us anything.
      
      Going to do kdevelop now.
      
      CCMAIL:kdevelop-devel@kdevelop.org 
      4c56ce7f
  24. 27 Aug, 2008 1 commit
  25. 26 Aug, 2008 1 commit
    • Evgeniy Ivanov's avatar
      - Changes in VcsCommitDialog and VcsStatusInfo to support DVCS. Also... · 76a5d2ca
      Evgeniy Ivanov authored
      - Changes in VcsCommitDialog and VcsStatusInfo to support DVCS. Also VcsCommitDialog uses different colors for different statuses (like QGit) now.
      - Now DistributedVersionControlPlugin uses VcsCommitDialog instead of CommitManager. CommitManager is removed. But it got few bugs I will fix them tomorrow.
      - IDVCSexecutor changes to work with VcsCommitDialog. Also some glitch fixes in GitExecutor.
      - A lot of different changes.
      
      CCMAIL: aleixpol@gmail.com
      Aleix, I did some changes in your code, because I did some API changes in DVCS.
      76a5d2ca
  26. 25 Aug, 2008 2 commits
    • Evgeniy Ivanov's avatar
    • Evgeniy Ivanov's avatar
      Squashed commit of the following: · 589f74f3
      Evgeniy Ivanov authored
          Basic Revision history implementation, including DVCScommit class and interface implementation for Git.
      It works correctly with simple revision history (actually it works fine with all things could be done with DVCS in KDevelop). Simple history with merges is ok too.
          Some API documentation (essential).
          Branching tests for GitExecutor (but can be used in all executors).
          Few Easter Eggs for translators :)
          Fixes for Git to allow CommitManager to work correctly with "no commits" repos.
          Some minor fixes/changes.
      589f74f3
  27. 02 Aug, 2008 1 commit
    • Andreas Pakulat's avatar
      Uff. Unify #include's across libs and plugins. · f4652711
      Andreas Pakulat authored
      The #include's now follow these rules:
      
      For libraries
       - #include <foo.h> / #include <Foo> for anything outside kdevplatform - i.e.
         other libraries
       - #include "foo.h" or #include "../foo.h" or #include "bar/foo.h" or #include
         "../bar/foo.h" for headers that are inside the same library
       - #include <bar/foo.h> for any library bar in kdevplatform
      
      For plugins
       - #include "foo.h" only for files inside the plugin
       - #include <bar/foo.h> for any kdevplatform library bar
       - #include <foo.h> / #include <Foo> for any other libs
      
      This allows us to remove all include_directories() calls, so we're only have -I
      switches for "external" libs (like KDE/Qt) and the top-level source/binary dir
      as well as the "current" source/binary dir.
      
      This is also supposed to make our header safer against include-problems, like
      using #include <icore.h> and that picks up a header of similar name from some
      other lib. 
      
      We've had a discussion about this quite a while back. Still if anybody feels
      like this still has problem please speak up.
      
      CCMAIL:kdevelop-devel@kdevelop.org
      f4652711
  28. 20 Jul, 2008 3 commits
  29. 16 Jul, 2008 1 commit
  30. 12 Jul, 2008 1 commit
  31. 11 Jul, 2008 1 commit
    • Evgeniy Ivanov's avatar
      CCMAIL: thomas.burdick@gmail.com · 3ee02d21
      Evgeniy Ivanov authored
      FEATURE: basic Git and Mercurial support.
      implemented DVCS base class which hould be used in all DVCS plugins, it prevents plugins from duplicating code
      fixed bug in git: now all system environment variables are set
      fixed bug in mercurial: job<<" "<<" " or job<<"";job<<""; should be used instead of job<<"one two"
      
      Thomas, sorry for removing your code. I was commiting to http://repo.or.cz/w/kdevelopdvcssupport.git because mercurial plugin had a bug (you did the same bug with job<< usage). If you want to help with DVCS: Bazaar is not implemented yet (but it required much less job, than you did to implement mercurial).
      3ee02d21
  32. 21 Jun, 2008 1 commit