Mailing-List: contact issues-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@continuum.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: 
 <4818334.1207119358442.JavaMail.haus-jira@codehaus01.managed.contegix.com>
Date: Wed, 2 Apr 2008 01:55:58 -0500 (CDT)
From: "Brett Porter (JIRA)" <jira@codehaus.org>
To: issues@continuum.apache.org
Subject: [jira] Updated: (CONTINUUM-415) cvs update log shows all updates,
 not just relevant updates
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


     [ http://jira.codehaus.org/browse/CONTINUUM-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brett Porter updated CONTINUUM-415:
-----------------------------------

    Fix Version/s:     (was: Future)
                   1.x

> cvs update log shows all updates, not just relevant updates
> -----------------------------------------------------------
>
>                 Key: CONTINUUM-415
>                 URL: http://jira.codehaus.org/browse/CONTINUUM-415
>             Project: Continuum
>          Issue Type: Bug
>          Components: SCM
>    Affects 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.x
>
>
> 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