[VCSIface] Difference between VcsEvent and VcsItemEvent

Andreas Pakulat apaku at gmx.de
Mon May 7 23:01:15 UTC 2007


On 07.05.07 16:49:45, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 07.05.07 09:54:01, Matthew Woehlke wrote:
> >> Andreas Pakulat wrote:
> >> log() doesn't tell you anything about other files 
> >> affected at the same time, for that you use change().
> > 
> > Why?
> 
> Because I don't expect callers of log() to often care about this, and to 
> get it from perforce is orders-of-magnitude more difficult. First you 
> use 'p4 filelog' to find out about the file. Then you use 'p4 describe' 
> to find out about each change that 'p4 filelog' tells you about. Then 
> you use 'p4 filelog' again on every item/revision pair to find out 
> correctly what the action is. So instead of one action, log() now has to 
> issue three in sequence.

Hmm, ok. So log() returns a quite small list of changes and to get more
verbose information one can use change(). Which I think resembles GUI's
that exist (at least for svn), where you also see a list of revisions
with author and message and when you double-click them you can see stuff
like files that where changed and how and possibly create a diff to the
previous version.

> I'd be OK making log() have the same result type, but that leaves four 
> options:
> 
> 1. Have inconsistent behavior as to whether or not you get "peripheral 
> information" from log().
> 1a. This means that if you want to track a single file, you have to do 
> it yourself. Bummer.
> 2. Always return information about /only/ the requested file, even if 
> more information is available
> 2a. This moves the burden of 1a from user-space to the plugin.
> 3. Make perforce's log() really, really slow due to having to execute an 
> additional operation for every result returned by log().
> 3a. ...and we still need change() unless you want to log() the 
> repository root.
> 4. Combine 1 and 3 (eliminating 1a) by adding a flag specifying if you 
> want to know about the changes as well.

See above, I do agree so far. Although I'd like to have another look at
the 3 helper classes to make it easier to recognize what each does by
looking at them. (without having to read the full dox).

But that has to wait til tomorrow.

Andreas

-- 
Your business will go through a period of considerable expansion.




More information about the KDevelop-devel mailing list