[#CCNET-639] Multiple Subversion Sourcecontrol repositories not supported in single project

CruiseControl .NET

Multiple Subversion Sourcecontrol repositories not supported in single project

Created: 18/Jan/06 11:15 PM Updated: 24/Nov/08 09:10 AM

Component/s:

Source Control

Affects Version/s:

1.0, 1.1.1

Fix Version/s:

1.4.1

Original Estimate:

Unknown

Remaining Estimate:

Unknown

Time Spent:

Unknown

Issue Links:

Relationship

This issue Relates to:
	CCNET-1230 CCNET should support source control s...

This issue Relates to:
	~~CCNET-1307~~ Multiple svn repositories support doe...

Description

« Hide

Todd Stibor wrote:

I have found a bug concerning multiple subversion repositories. I will try to address it but I was wondering if anyone else has already found this issue and has a solution for it.

We are using Subversion to build a large complex project.

We have three repositories: A, B and C.
A depends on B which depends on C.

C is at revision level 5
B is at revision level 11
A is at revision level 8

Here is our source control block
<sourcecontrol type="multi">
        <sourceControls>
                <svn>
                        <trunkUrl>http://server/SVN/C</trunkUrl>
                        <workingDirectory>E:\ccNetBuild\projects\C</workingDirectory>
                        <executable>C:\Program Files\Subversion\bin\svn.exe</executable>
                        <username>username</username>
                        <password>password</password>
                        <autoGetSource>true</autoGetSource>
                </svn>
                <svn>
                        <trunkUrl>http://server/SVN/B</trunkUrl>
                        <workingDirectory>E:\ccNetBuild\projects\B</workingDirectory>
                        <executable>C:\Program Files\Subversion\bin\svn.exe</executable>
                        <username>username</username>
                        <password>password</password>
                        <autoGetSource>true</autoGetSource>
                </svn>
                <svn>
                        <trunkUrl>http://server/SVN/A</trunkUrl>
                        <workingDirectory>E:\ccNetBuild\projects\A</workingDirectory>
                        <executable>C:\Program Files\Subversion\bin\svn.exe</executable>
                        <username>username</username>
                        <password>password</password>
                        <autoGetSource>true</autoGetSource>
                </svn>
        </sourceControls>
</sourcecontrol>

When a build kicks off for this project we get the following error:

BUILD EXCEPTION Error Message: ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: svn: REPORT request failed on '/SVN/Microkernel/!svn/vcc/default' svn: No such revision 11 .

Process command: C:\Program Files\Subversion\bin\svn.exe update --revision 11 --username username --password password --non-interactive

at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo processInfo)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Svn.GetSource(IIntegrationResult result)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.MultiSourceControl.GetSource(IIntegrationResult result)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.RunIntegration(BuildCondition buildCondition) Project: DMS

I believe the issue is in the Svn module, the LastChangeNumber being stored in the result parameter is the largest revision number for all repositories. The module will then try to get revision 8 for all three repositories, when not all repositories have a revision 8, specifically the "C" repository.

Reference: ThoughtWorks.CruiseControl.Core.IntegrationResult.LastChangeNumber property and
ThoughtWorks.CruiseControl.Core.Sourcecontrol.MultiSourceControl.GetSource method and
ThoughtWorks.CruiseControl.Core.Sourcecontrol.Svn.NewGetSourceProcessInfo method

Description

Todd Stibor wrote: I have found a bug concerning multiple subversion repositories. I will try to address it but I was wondering if anyone else has already found this issue and has a solution for it. We are using Subversion to build a large complex project. We have three repositories: A, B and C. A depends on B which depends on C. C is at revision level 5 B is at revision level 11 A is at revision level 8 Here is our source control block <sourcecontrol type="multi"> <sourceControls> <svn> <trunkUrl>http://server/SVN/C</trunkUrl> <workingDirectory>E:\ccNetBuild\projects\C</workingDirectory> <executable>C:\Program Files\Subversion\bin\svn.exe</executable> <username>username</username> <password>password</password> <autoGetSource>true</autoGetSource> </svn> <svn> <trunkUrl>http://server/SVN/B</trunkUrl> <workingDirectory>E:\ccNetBuild\projects\B</workingDirectory> <executable>C:\Program Files\Subversion\bin\svn.exe</executable> <username>username</username> <password>password</password> <autoGetSource>true</autoGetSource> </svn> <svn> <trunkUrl>http://server/SVN/A</trunkUrl> <workingDirectory>E:\ccNetBuild\projects\A</workingDirectory> <executable>C:\Program Files\Subversion\bin\svn.exe</executable> <username>username</username> <password>password</password> <autoGetSource>true</autoGetSource> </svn> </sourceControls> </sourcecontrol> When a build kicks off for this project we get the following error: BUILD EXCEPTION Error Message: ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: svn: REPORT request failed on '/SVN/Microkernel/!svn/vcc/default' svn: No such revision 11 . Process command: C:\Program Files\Subversion\bin\svn.exe update --revision 11 --username username --password password --non-interactive at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo processInfo) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Svn.GetSource(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.MultiSourceControl.GetSource(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.IntegrationRunner.RunIntegration(BuildCondition buildCondition) Project: DMS I believe the issue is in the Svn module, the LastChangeNumber being stored in the result parameter is the largest revision number for all repositories. The module will then try to get revision 8 for all three repositories, when not all repositories have a revision 8, specifically the "C" repository. Reference: ThoughtWorks.CruiseControl.Core.IntegrationResult.LastChangeNumber property and ThoughtWorks.CruiseControl.Core.Sourcecontrol.MultiSourceControl.GetSource method and ThoughtWorks.CruiseControl.Core.Sourcecontrol.Svn.NewGetSourceProcessInfo method

Show »

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Martin Aliger [20/Jan/06 03:05 AM]

I believe it could work on old versions using dates. But there was other issues-getting source via revision numbers is much better. I'd like to see patch for this in MultiSourceControl side. Nothing easy it seems.

[ Permlink | « Hide ]

Ron Kim [02/Apr/06 03:39 PM]

I'm working with 1.0.1 now and I still see that error message. It's not giving us too much trouble but it would be nice without it :D
How's it coming along?

[ Permlink | « Hide ]

Tony Kyle [20/Apr/06 11:37 AM]

I would create separate projects in ccnet.config and make A and B dependent builds using the split build steps outlined in the documentation.

[ Permlink | « Hide ]

Vlad Romanenko [30/Nov/06 03:03 AM]

This is still a problem with version 1.1.1

[ Permlink | « Hide ]

John Reynolds [08/Mar/07 08:33 AM]

Is this on anybody's radar screen? Still a problem over a year later... I'd love to see a fix for this in the next release...

Thanks!
John

[ Permlink | « Hide ]

Ilya Staheev [27/Sep/07 07:34 AM]

Another situatuion:

I have two repositories, called A and B, where B linked to A via 'svn:externals' attribute. I want to trigger build when one of this repositories changes, but CruiseControl must perform checkout only for A. A and B described in <sourceControls> block, but B has 'autoGetSource' set to 'false'. CruiseControl detected changes in both repositories but trying to checkout A with revision number from B when B changes.

I'm using CruiseControl.NET, v1.3.

Thanks.

[ Permlink | « Hide ]

John Hauppa [02/Jan/08 01:23 PM]

I know this has already been reported, but I am also seeing this or a similar error intermittantly when using the <sourceControls> with multiple svn.

I just upgraded to the latest build that I could find (1.3.0.2918) and it does not fix the issue.

"ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: svn: REPORT request failed on '/svn/!svn/vcc/default'
svn: Cannot replace a directory from within"

Thanks,
John

[ Permlink | « Hide ]

Brad Stowers [09/Jun/08 04:17 PM]

I have this problem as well. Any news on when/if it will be fixed? I'd be happy to help any way I can, providing logs, etc.

Thanks,
Brad

[ Permlink | « Hide ]

torkjel hongve [30/Jun/08 09:55 AM]

I also bumped into this issue. As a temporary solution, I've made a private build that has one line in Svn.cs commented out:

private ProcessInfo NewGetSourceProcessInfo(IIntegrationResult result)
{
ProcessArgumentBuilder buffer = new ProcessArgumentBuilder();
buffer.AddArgument("update");
// AppendRevision(buffer, result.LastChangeNumber);
AppendCommonSwitches(buffer);
return NewProcessInfo(buffer.ToString(), result);
}

This will cause it to always check out the latest version of each repository, instead of the specific (non existing) version.

This is clearly not the Right Thing, but I believe the only consequence is that the modification log can be incomplete in some cases. Hoping for a proper fix soon, preferrably one that makes it possible to define several repositories in one <svn> tag.

[ Permlink | « Hide ]

Ross Patterson [20/Jul/08 07:54 PM]

FYI, this problem has nothing to do with Subversion. The problem is that CCNET only knows about one Last Change Number for a project, regardless of how many source control blocks the project contains. This problem can also occur when using more than one type of source control system, in which case it is very unlikely that the systems will understand each other's numbers.

Any fix should find some way to store a separate LastChangeNumber field in the state data for *each* source control block. That's a pretty complicated change to a core part of the system.

[ Permlink | « Hide ]

Ross Patterson [25/Aug/08 01:11 PM]

Revision #4046 fixes this for both AccuRev and Subversion, the only two sourcecontrol implementations that attempt to update the source to the LastChangeNumber level. The fix is to have them remember what modifications they contributed to the overall set, and to compute the update-target change number only against that subset.