SVN Adapter 'Conflict'

Question

I've setup a bi-directional configuration using the SVN Adapter, and when starting the migration I get a runtime conflict 'The Credential of the subversion client is not specified'.

It appears the application connects to SVN, authenticates and processes the current SVN revision successfully using the configured SVN username/password.

Can anyone please tell me what this error means?

Answer 1

Hi Stuart:

I am not sure this is exactly the issue you  are experiencing but I think the tool only works for a mgration from SVN to TFS.  It does not work bi-directionally.  See the documentation. (C:\Program Files (x86)\Microsoft Team Foundation Server Integration Tools\Documentation\Readiness Package\Guidance\TFS_Integration_Platform-Subversion_Migration.mht)

Try a one way sync and see if the error goes away?

Wendell

Answer 2

Hi Wendell,

Thanks for the response.  It doesn't matter which type of synch I choose, One-Way, Two Way or Custom give me the exact same message.

Here's the detail:

 

[01/08/2011 08:11:07] TfsMigrationShell.exe Information: 0 : VersionControl: Unresolved conflict: 
[01/08/2011 08:11:07]  Session: c3585dac-e10f-4c2b-b547-fe3bbfc22154 
[01/08/2011 08:11:07]  Source: 9547d79a-5278-4889-94dd-8ca8f75ef042 
[01/08/2011 08:11:07]  Message: Cannot find applicable resolution rule. 
[01/08/2011 08:11:07]  Conflict Type: Runtime Error 
[01/08/2011 08:11:07]  Conflict Type Reference Name: f6dab314-2792-40d9-86cc-b40f5b827d86 
[01/08/2011 08:11:07]  Conflict Details: Microsoft.TeamFoundation.Migration.Toolkit.MigrationException: SubversionClient: The Credential of the subversion client is not specified. 
[01/08/2011 08:11:07]  at Microsoft.TeamFoundation.Migration.SubversionAdapter.Interop.Subversion.SubversionClient.InitializeContext(apr_pool_t* pool) 
[01/08/2011 08:11:07]  at Microsoft.TeamFoundation.Migration.SubversionAdapter.Interop.Subversion.SubversionClient.GetRepositoryRoot(String path) 
[01/08/2011 08:11:07]  at Microsoft.TeamFoundation.Migration.SubversionAdapter.SubversionOM.Repository.EnsureAuthenticated() 
[01/08/2011 08:11:07]  at Microsoft.TeamFoundation.Migration.SubversionAdapter.SubversionOM.Repository.GetItems(String path, Int32 revision, Depth depth) 
[01/08/2011 08:11:07]  at Microsoft.TeamFoundation.Migration.SubversionAdapter.SubversionAnalysisAlgorithms.ProcessFolderBranch(Change change, ChangeGroup group) 
[01/08/2011 08:11:07]  at Microsoft.TeamFoundation.Migration.SubversionAdapter.SubversionAnalysisAlgorithms.Branch(Change change, ChangeGroup group) 
[01/08/2011 08:11:07]  at Microsoft.TeamFoundation.Migration.SubversionAdapter.SubversionAnalysisAlgorithms.Execute(Change change, ChangeGroup changeGroup) 
[01/08/2011 08:11:07]  at Microsoft.TeamFoundation.Migration.SubversionAdapter.SubversionVCAnalysisProvider.analyzeChangeset(ChangeSet changeSet, Int32[] mappedChanges) 
[01/08/2011 08:11:07]  at Microsoft.TeamFoundation.Migration.SubversionAdapter.SubversionVCAnalysisProvider.GenerateDeltaTable() 
[01/08/2011 08:11:07]  at Microsoft.TeamFoundation.Migration.Toolkit.AnalysisEngine.GenerateDeltaTables(Guid sourceId) 
[01/08/2011 08:11:07] 

Answer 3

Stuart, I have the exact same problem.  Were you ever able to get this resolved?

Answer 4

Unfortunately no!  Pressure came from elsewhere and so my investigations into this got shelved, but it's still something I am keen to resolve.

We have recently upgraded our SVN repository to 1.7 and it has been in the back of my mind to try again, but I've not had any time to look at it further.