DamageControl

Using a branch in CVS triggers a changeset with everything changed in every poll

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 0.4
  • Fix Version/s: None
  • Component/s: CVS
  • Labels:
    None
  • Environment:
    Windows XP, Cygwin Ruby, Cygwin CVS
  • Number of attachments :
    0

Description

Steps to reproduce:
1. Create a project that checks out a branch from CVS
2. Use polling
3. Every time DC polls, it finds a changeset including all changes of that branch (from the beginning of the branch I think)
4. A new build is started with the full changeset.

Expected behaviour:
3. Only find the last changes in that branch.
4. Do not build when nothing has changed in the branch.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Alexander Klimetschek added a comment -

This problem is a bit more difficult....

After a restart and switching on polling again it worked. There was one change in the repository in the meantime, he correctly recognized it and everything was fine.

The next time he polled, he found the old changes again (1 week and 2 weeks ago...), the same as in the original bug description.

So it seems like there is a bug in the log-parser. My first idea was that the cvs log command used for the changeset is wrong, but a look at the sources showed this is not the case.

Show
Alexander Klimetschek added a comment - This problem is a bit more difficult.... After a restart and switching on polling again it worked. There was one change in the repository in the meantime, he correctly recognized it and everything was fine. The next time he polled, he found the old changes again (1 week and 2 weeks ago...), the same as in the original bug description. So it seems like there is a bug in the log-parser. My first idea was that the cvs log command used for the changeset is wrong, but a look at the sources showed this is not the case.
Hide
Permalink
Alexander Klimetschek added a comment -

Important: This also happens with the MAIN branch!

It has nothing to do with branching, the problem is generally that for some reasons the entire changeset is recognized!

Show
Alexander Klimetschek added a comment - Important: This also happens with the MAIN branch! It has nothing to do with branching, the problem is generally that for some reasons the entire changeset is recognized!
Hide
Permalink
Aslak Hellesøy added a comment -

Just some additional info that may not be apparrent:

DC's CVS calculates changesets specifying a from-time and no to-time. Example:

cvs '-d:ext:dcontrol@cvs.groovy.codehaus.org:/scm/groovy' log -N -S -d"2004-12-09 22:33:32 UTC<="

The from-time is taken from the previous build's scm_commit_time field. Every time changesets are calculated, the current build's scm_commit_time is set to that of the latest changeset (should ideally be that latest change, not changeset but that's a different story).

This means that the first time changesets are computed, there is no previous build, and therefore no from-time either. As a result, for new projects, the first changeset computation will take the entire history log and identify the last scm_commit_time from that.

Since this is potentially a huuuuge changeset, the first build for a project will not persist the changeset. (It is only calculated to identify the last commit time and then discarded forever, not persisted anywhere).

I don't know if this is directly relevant to this bug, but it's good to know anyway

Also see http://archive.damagecontrol.codehaus.org/dev/messages/163 for more details on timestamps and changesets.

Show
Aslak Hellesøy added a comment - Just some additional info that may not be apparrent: DC's CVS calculates changesets specifying a from-time and no to-time. Example: cvs '-d:ext:dcontrol@cvs.groovy.codehaus.org:/scm/groovy' log -N -S -d"2004-12-09 22:33:32 UTC<=" The from-time is taken from the previous build's scm_commit_time field. Every time changesets are calculated, the current build's scm_commit_time is set to that of the latest changeset (should ideally be that latest change, not changeset but that's a different story). This means that the first time changesets are computed, there is no previous build, and therefore no from-time either. As a result, for new projects, the first changeset computation will take the entire history log and identify the last scm_commit_time from that. Since this is potentially a huuuuge changeset, the first build for a project will not persist the changeset. (It is only calculated to identify the last commit time and then discarded forever, not persisted anywhere). I don't know if this is directly relevant to this bug, but it's good to know anyway Also see http://archive.damagecontrol.codehaus.org/dev/messages/163 for more details on timestamps and changesets.

People

  • Assignee:
    Unassigned
    Reporter:
    Alexander Klimetschek
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: