continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Ewins (JIRA)" <>
Subject [jira] Created: (CONTINUUM-415) cvs update log shows all updates, not just relevant updates
Date Wed, 02 Nov 2005 18:16:45 GMT
cvs update log shows all updates, not just relevant updates

         Key: CONTINUUM-415
     Project: Continuum
        Type: Bug
  Components: continuum-core  
    Versions: 1.0    
 Environment: WinXP
Client: Concurrent Versions System (CVSNT) 2.5.02 (Servalan) Build 2115 (client/server)
Server: Concurrent Versions System (CVSNT) 2.0.34 (client/server)
 Reporter: Brian Ewins

To reproduce, perform a build on a project which uses CVS. Take a look at the results for
the build What I see is the list of files changed in the most recent update, followed by the
author and comment for /every/ commit on those files /ever/.  What I expected to see was (at
best) only changes since the last build, or (at least) only recent changes, say in the last
day or two.

I've traced this one down a bit, the cause is quite convoluted; the code producing the log
is making an incorrect assumption about the ScmResults created on updates. Here's the call
sequence that's messing up as far as I can tell (from browsing svn and correlating with the
log messages I see):

-..after a couple of steps..-> DefaultContinuumScm.updateProject(project)
-> [ScmResult] result = convertScmResult(
                    scmManager.getProviderByRepository( repository ).update( repository, fileSet,
tag ) )
-> [CvsScmProvider].update(repository, fileSet, tag)
-> [AbstractUpdateCommand].execute( repository.getProviderRepository(), fileSet, parameters
-> (ChangeLogScmResult) [AbstractChangeLogCommand].executeCommand( repository,
            parameters ); 
-> [CvsChangeLogCommand].executeCommand(repository, fileSet, null, null, 0, branch)
This then calls cvs log with no date limiting parameters, so the ScmResult for the update
contains the full log, although it is trimmed to just the files that changed.

then later on, when asked to produce the build log:
DefaultContinuum.getChangesSinceLastSuccess(projectId, buildId)
-> changes.addAll( buildResult.getScmResult().getChanges() );
This adds all the changes recorded in that build result, which the previous trace shows are
actually all changes, ever. This set of changes isn't then filtered by date.

>From the looks of 'getChangesSinceLastSuccess' its supposed to provide a list of all changes
from build 'buildId' up to the current one. The assumption in that method appears to be that
each buildResult contains only appropriate changes. However, since it contains /all/ changes,
I'd expect that the situation is much worse: multiple changes to a file since the last build
will mean we get multiple copies of /all/ changes to that file dumped into the log.

There's some kind of logical disconnect here. I think what's missing is that the call to 'scmManager.getProviderByRepository(
repository ).update( repository, fileSet, tag ) ' should actually be passing in the timestamp
of the previous build, so that we can retrieve just changes since that build: that way the
assumption in 'getChangesSinceLastSuccess' is correct. - that the changes from multiple builds
can just be appended together. 

If I've diagnosed this wrong, then it means that whatever's meant to filter down the changes
to just those since the last build isn't working. I couldn't find any code that was actually
attempting to do that, though.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message