Continuum (moved to ASF)
  1. Continuum (moved to ASF)
  2. CONTINUUM-1640

No changes and no committer name extracted from SVN

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.1
    • Fix Version/s: 1.4.1
    • Component/s: SCM
    • Labels:
      None
    • Environment:
      Windows XP, Java 1.5, SVN 1.4.3
    • Complexity:
      Intermediate
    • Patch Submitted:
      Yes
    • Number of attachments :
      1

      Description

      When continuum detects changes and makes builds, no data is extracted on change date and committer.

      It always looks like this

      ****************************************************************************
      SCM Changes:
      ****************************************************************************
      Changed: no author @ no date
      Comment: no comment
      Files changed:
      (here are files)

      It is the same machine (SVN/continuum) so we rule out ime difference immediately.

      Moreover I've checked in continuum logs, there is "svn --non-interactive log" command executed, and when I type this command in, proper dates and commiters are displayed.

      looking at org.apache.maven.continuum.scm.DefaultContinuumScm, I've found that change date/commiters are taken from ScmResult that comes from this method
      scmResult = scmManager.getProviderByRepository( repository ).update( repository, fileSet, tag, getLatestUpdateDate( project ) );
      result = convertScmResult( scmResult );

      Maven SVN SCM Manager returns no changes in scmResult.getChanges()

      Where this svn log command is coming from then? Not from Maven SCM but from continuum itself?

        Activity

        Hide
        Kalle Korhonen added a comment -

        Verifying I"m seeing the same issue on WindowsXP; not sure if that's the culprit, but I've been running multiple Continuum instances before and never seen this. I can also see that on some updates we have gotten date & author correctly without anything else changes as far as I know of. Any workaround for the short term would be useful if anyone knows what the issue is.

        Show
        Kalle Korhonen added a comment - Verifying I"m seeing the same issue on WindowsXP; not sure if that's the culprit, but I've been running multiple Continuum instances before and never seen this. I can also see that on some updates we have gotten date & author correctly without anything else changes as far as I know of. Any workaround for the short term would be useful if anyone knows what the issue is.
        Hide
        Emmanuel Venisse added a comment -

        Dates on your servers are probably not synced

        Show
        Emmanuel Venisse added a comment - Dates on your servers are probably not synced
        Hide
        Timur Evdokimov added a comment -

        Emmanuel, which 'servers' do you mean?
        It is one physical machine with Subversion and Continuum.

        Please look at my comment in more details, like I said in Continuum code I don't see how svn change data is retrieved.

        Show
        Timur Evdokimov added a comment - Emmanuel, which 'servers' do you mean? It is one physical machine with Subversion and Continuum. Please look at my comment in more details, like I said in Continuum code I don't see how svn change data is retrieved.
        Hide
        Timur Evdokimov added a comment -

        The reason given in resolution is not applicable to the situation I reported.

        If you need more logs, information, etc. I'd be happy to provide you with it.

        Show
        Timur Evdokimov added a comment - The reason given in resolution is not applicable to the situation I reported. If you need more logs, information, etc. I'd be happy to provide you with it.
        Hide
        Timur Evdokimov added a comment -

        To my surprise, I found today that it works perfectly when a committer is authentified by 'normal' HTTP password authentication.

        However when a change is committed by a user with HTTPS client certificate authentication (SSLOptions +FakeBasicAuth) - then the above problem appears.

        Could it be because committer name in the latter case will be like "/CN=Timur Evdokimov", as opposed to just "timur.evdokimov" in the former case?

        Show
        Timur Evdokimov added a comment - To my surprise, I found today that it works perfectly when a committer is authentified by 'normal' HTTP password authentication. However when a change is committed by a user with HTTPS client certificate authentication (SSLOptions +FakeBasicAuth) - then the above problem appears. Could it be because committer name in the latter case will be like "/CN=Timur Evdokimov", as opposed to just "timur.evdokimov" in the former case?
        Hide
        Baptiste MATHUS added a comment -

        Well, we're also having this issue, although we exclusively use svn:// protocol. Note this bug is also only on certain commit, not all. I already tried a bit to identify the source of this, but couldn't find the "parameters" of reproducibility of this bug...

        Show
        Baptiste MATHUS added a comment - Well, we're also having this issue, although we exclusively use svn:// protocol. Note this bug is also only on certain commit, not all. I already tried a bit to identify the source of this, but couldn't find the "parameters" of reproducibility of this bug...
        Hide
        Emmanuel Venisse added a comment -

        Baptiste,

        To try to reproduce, rename or move a file in your svn, then let Continuum build your project.
        Let me know if you can reproduce it.

        Show
        Emmanuel Venisse added a comment - Baptiste, To try to reproduce, rename or move a file in your svn, then let Continuum build your project. Let me know if you can reproduce it.
        Hide
        Kalle Korhonen added a comment -

        In our case, the problem really was the differing time between Continuum server and svn server; two hours off on Continuum server was enough to throw it off every now and then. It'd be nicer if it'd fail somewhat more predictably but thanks to Emmanuel for the tip.

        Show
        Kalle Korhonen added a comment - In our case, the problem really was the differing time between Continuum server and svn server; two hours off on Continuum server was enough to throw it off every now and then. It'd be nicer if it'd fail somewhat more predictably but thanks to Emmanuel for the tip.
        Hide
        Brett Porter added a comment -

        pushing out, but we should be able to measure against a single time source

        Show
        Brett Porter added a comment - pushing out, but we should be able to measure against a single time source
        Hide
        Immanuel Scheerer added a comment -

        I stepped into the same problem because our LDAP users contain a space character. The current regular expressions from the project "maven-scm-provider-svnexec" used to parse the svn log do not match when the author contains a space. I will attach the fix that works for me.

        Show
        Immanuel Scheerer added a comment - I stepped into the same problem because our LDAP users contain a space character. The current regular expressions from the project "maven-scm-provider-svnexec" used to parse the svn log do not match when the author contains a space. I will attach the fix that works for me.
        Hide
        Immanuel Scheerer added a comment - - edited

        Attached the fix that works for me.

        Show
        Immanuel Scheerer added a comment - - edited Attached the fix that works for me.
        Hide
        Brent N Atkinson added a comment -

        It appears that this issue was already taken care of with an upgrade of maven-scm. This is consistent with the contents of the patch, which includes code for maven-scm classes and not Continuum's.

        The issue was also reported as SCM-455 to the maven-scm project and according to Jira it was fixed in maven-scm 1.3. The first release bundling a version of maven-scm greater than 1.3 was Continuum 1.4.1, which uses maven-scm 1.4.

        I adapted the test case and added to continuum-scm just to verify that the issue is fixed. I had to change the changelog format for the first entry however, because it no longer appears to parse with modern versions of Subversion. This should not affect the outcome for author parsing, but it is worth noting that the test case is not identical.

        Show
        Brent N Atkinson added a comment - It appears that this issue was already taken care of with an upgrade of maven-scm. This is consistent with the contents of the patch, which includes code for maven-scm classes and not Continuum's. The issue was also reported as SCM-455 to the maven-scm project and according to Jira it was fixed in maven-scm 1.3. The first release bundling a version of maven-scm greater than 1.3 was Continuum 1.4.1, which uses maven-scm 1.4. I adapted the test case and added to continuum-scm just to verify that the issue is fixed. I had to change the changelog format for the first entry however, because it no longer appears to parse with modern versions of Subversion. This should not affect the outcome for author parsing, but it is worth noting that the test case is not identical.
        Hide
        Brent N Atkinson added a comment -

        I am setting the fix version to 1.4.1 since that is when the issue was actually fixed. The test has been applied to trunk@r1654973.

        Show
        Brent N Atkinson added a comment - I am setting the fix version to 1.4.1 since that is when the issue was actually fixed. The test has been applied to trunk@r1654973.

          People

          • Assignee:
            Brent N Atkinson
            Reporter:
            Timur Evdokimov
          • Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: