Continuum

No changes and no committer name extracted from SVN

Details

  • Type: Bug Bug
  • Status: Reopened Reopened
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.1
  • Fix Version/s: 1.5.0
  • 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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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.

People

  • Assignee:
    Emmanuel Venisse
    Reporter:
    Timur Evdokimov
Vote (3)
Watch (4)

Dates

  • Created:
    Updated: