continuum-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Porter (JIRA)" <j...@codehaus.org>
Subject [jira] Closed: (CONTINUUM-415) cvs update log shows all updates, not just relevant updates
Date Wed, 22 Apr 2009 14:35:45 GMT

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

Brett Porter closed CONTINUUM-415.
----------------------------------

      Assignee: Brett Porter
    Resolution: Cannot Reproduce

not seeing this in r 767397

> 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
>            Assignee: Brett Porter
>
> 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

        

Mime
View raw message