Bug 82742

Summary:	When KDevelop rescans an updated project a synposis of the updates would be helpful
Product:	[Applications] kdevelop	Reporter:	Nick Savoiu <savoiu>
Component:	general	Assignee:	kdevelop-bugs-null
Status:	RESOLVED INTENTIONAL
Severity:	wishlist
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Nick Savoiu 2004-06-03 02:03:21 UTC

Version:           3.0.90 (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc3.2 
OS:                Linux

I see that KDevelop spends quite a few cycles determining what in the project has changed (added classes, methods, typedefs, etc.). 

I think it would be useful if the user would be presented with a list (a la CTAGS) of the added/changed/removed items. We can probably refine/filter what/how things would be displayed.

One particular use for this I think would be in large, multideveloper projects. It would alert one to new functionality that was added. Say a helper function for a tedious piece of code has been written. Getting the notification would allow me to at a glance (if others use descriptive names) see if such code that I might find useful has been added.

Perhaps even the KDevelop developers could use this :)

What do you guys think?

Comment 1 Steven T. Hatton 2004-06-03 07:51:41 UTC

This is something so obvious to me, I have wondered why it is not a standard feature of CVS. Just today I was going through the painful exercise of trying to identify recent changes, which I had a feature like this.  I believe one way to do it would be to recurse the tree looking at the timestamps, and comparing them to a local timestamp representing your previous update.  The files I'm talking about are the ./CVS/Entries files which look like  

/.cvsignore/1.23/Sun Oct  5 15:10:27 2003//
/AUTHORS/1.48/Tue Feb 24 14:42:59 2004//
/COPYING/1.6/Fri Oct  3 18:08:08 2003//
/COPYING.LIB/1.1/Mon May 27 10:52:09 2002//
/ChangeLog/1.1139/Mon May 31 20:33:09 2004//
/Doxyfile.am/1.28/Wed Jan  7 22:18:22 2004//
/Doxyfile.onlineAPI/1.3/Mon Feb 16 22:24:53 2004//
/HACKING/1.5/Mon Sep 22 21:24:08 2003//
/HACKING.language/1.3/Mon Sep 22 17:46:03 2003//
/INSTALL/1.6/Wed Apr  4 16:58:07 2001//
/Makefile.am/1.96/Mon May 31 11:01:31 2004//
/Makefile.cvs/1.10/Wed Apr  4 17:01:39 2001//
/NEWS/1.1.1.1/Wed Apr  4 16:44:58 2001//
/README/1.27/Thu Oct  2 15:53:17 2003//
/TODO/1.84/Thu Jan 22 03:42:28 2004//
/configure.in.bot/1.8/Sat Jun 14 21:51:15 2003//
/configure.in.in/1.75/Mon May 31 11:01:31 2004//
/kdevassistant.desktop/1.8/Mon May 24 07:51:16 2004//
/kdevelop.desktop/1.49/Thu May 27 07:35:40 2004//
/kdevelop.kdevelop/1.7/Fri Mar 19 00:25:04 2004//
/kdevelop.lsm/1.11/Mon Apr  5 07:11:22 2004//
/kdevelop.m4.in/1.37/Fri May 21 14:17:40 2004//
/kdevprj2kdevelop/1.3/Tue Jul 15 17:54:41 2003//
/x-kdevelop.desktop/1.25/Thu May 27 07:39:49 2004//

Comment 2 Andreas Pakulat 2008-06-29 20:10:39 UTC

This is close to impossible. Basically KDevelop would need to do versioning on its code-model to get this information. And IMHO this is far to much work for something thats far better solved with proper commit messages in your version control system and of course reading the commit messages of other devs.