[ http://jira.codehaus.org/browse/CONTINUUM-415?page=all ]
Emmanuel Venisse updated CONTINUUM-415:
---------------------------------------
Fix Version: 1.1
> cvs update log shows all updates, not just relevant updates
> -----------------------------------------------------------
>
> Key: CONTINUUM-415
> URL: http://jira.codehaus.org/browse/CONTINUUM-415
> Project: Continuum
> Type: Bug
> Components: Core system
> 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
> Fix For: 1.1
>
>
> 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):
> DefaultContinuum.buildProject(various)
> -..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,
>
> fileSet,
>
> 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:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
