[7601] Problems with svn:externals

Hello, I'm having troubles with externals in TeamCity. I really can't
understand why, but TeamCity tries to get the same revision of the main
project repository (at least that's what I coudl gather from reading the
log):
WARN - Triggers.vcs.svn.SvnConnection - Cannot
process externals: C:\ex\GEOLink\bin url=
https://shiva:8443/svn/Customers/Ronysul/GEOLink.bin; svn: No such
revision 81
svn: REPORT of '/svn/Customers/Ronysul/GEOLink.bin/!svn/vcc/default': 500
Internal Server Error (https://shiva:8443)
org.tmatesoft.svn.core.SVNException: svn: No such revision 81
svn: REPORT of '/svn/Customers/Ronysul/GEOLink.bin/!svn/vcc/default': 500
Internal Server Error (https://shiva:8443)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1191)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:1055)
at org.tmatesoft.svn.core.io.SVNRepository.update(SVNRepository.java:1640)
at
jetbrains.buildServer.buildTriggers.vcs.svn.SvnConnection.exportFiles(SvnConnection.java:463)
at
jetbrains.buildServer.buildTriggers.vcs.svn.SvnConnection.buildPatch(SvnConnection.java:229)
at
jetbrains.buildServer.buildTriggers.vcs.svn.SvnConnection.processExternalsPatch(SvnConnection.java:426)
at
jetbrains.buildServer.buildTriggers.vcs.svn.SvnConnection.buildPatch(SvnConnection.java:166)
at
jetbrains.buildServer.buildTriggers.vcs.svn.SvnSupport.buildPatch(SvnSupport.java:130)
at
jetbrains.buildServer.vcs.VcsSupportUtil.buildPatch(VcsSupportUtil.java:4)
at
jetbrains.buildServer.buildTriggers.vcs.svn.SvnSupport.buildPatch(SvnSupport.java:57)
at
jetbrains.buildServer.serverSide.impl.projectSources.SmallPatchCache.getCachedCleanPatch(SmallPatchCache.java:15)
at
jetbrains.buildServer.serverSide.impl.projectSources.PatchCacheImpl.buildCleanPatch(PatchCacheImpl.java:14)
at
jetbrains.buildServer.serverSide.impl.projectSources.PatchComposer.buildPatch(PatchComposer.java:53)
at
jetbrains.buildServer.serverSide.impl.projectSources.PatchComposer.buildPatch(PatchComposer.java:112)
at
jetbrains.buildServer.serverSide.impl.projectSources.PatchComposer.buildPatch(PatchComposer.java:114)
at
jetbrains.buildServer.serverSide.impl.BuildTypeImpl.buildPatch(BuildTypeImpl.java:487)
at
jetbrains.buildServer.serverSide.impl.BuildTypeImpl$$FastClassByCGLIB$$a84db719.invoke() at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149) at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:700) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at jetbrains.buildServer.serverSide.impl.auth.TeamCityMethodSecurityInterceptor.invoke(TeamCityMethodSecurityInterceptor.java:10) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.Cglib2AopProxy$FixedChainStaticTargetInterceptor.intercept(Cglib2AopProxy.java:582) at jetbrains.buildServer.serverSide.impl.BuildTypeImpl$$EnhancerByCGLIB$$75b16670.buildPatch(]]>)
at
jetbrains.buildServer.serverSide.impl.BuildStarter$2.call(BuildStarter.java:17)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)

There are other externals with a similar configuration in the same
project, that don't have this problem...it obviously doesn't seem to be a
problem with SVN as my developer computers work correctly.

Any ideas?

Regards,
Pablo

--


People don't form relationships, they take hostages.

Pablo Montilla
www.odyssey.com.uy

8 comments

Hello Pablo,

It looks like you've encountered a bug in our SVN support. In this EAP build, we tried to eliminate the need of time synchronization
between SVN server and TeamCity, so you've found a problem in our new code.

Could you please provide some additional information:
- teamcity-vcs.log from the server
- whether your externals reference same repository or another one
- sample of working externals definition
- sample of non-working externals definition

Thanks!

KIR

0

On Wed, 10 Sep 2008 04:24:07 -0300, Kirill Maximov (JetBrains)
<no_reply@jetbrains.com> wrote:

Hello Pablo,

>

It looks like you've encountered a bug in our SVN support. In this
EAP build, we tried to eliminate the need of time synchronization
between SVN server and TeamCity, so you've found a problem in our new
code.

>

Could you please provide some additional information:
- teamcity-vcs.log from the server
- whether your externals reference same repository or another one
- sample of working externals definition
- sample of non-working externals definition

>

Thanks!

>

KIR


The externals reference other repositories in the same server.

They seem to be trying to be checked into the C:\ directory (something
that the first versions of TC did, if I remember correctly).

Regards,
Pablo

PS: Save us! =)

--


It may be remarked for the comfort of honest poverty, that avarice
reigns most in those who have but few good qualities to recommend
them. This is a weed that will grow in a barren soil.
-- Hughes

Pablo Montilla
www.odyssey.com.uy



Attachment(s):
TeamCity.rar
0

Hello,

Do I understand correctly that failing externals like
/svn/Tools/RunIE.bin and /svn/Other/NUnit.lib
are referenced from https://shiva:8443/svn/Tools/MGW project?

And these referenced externals have own repositories?

Could you please run svn info command for https://shiva:8443/svn/Tools/MGW and
https://shiva:8443/svn/Tools/RunIE.bin repositories and attach results?

Thanks!
KIR

0

On Fri, 12 Sep 2008 12:36:45 -0300, Kirill Maximov (JetBrains)
<no_reply@jetbrains.com> wrote:

Hello,

>

Do I understand correctly that failing externals like
/svn/Tools/RunIE.bin and /svn/Other/NUnit.lib
are referenced from https://shiva:8443/svn/Tools/MGW project?

>

And these referenced externals have own repositories?

>

Could you please run svn info command for
https://shiva:8443/svn/Tools/MGW and
https://shiva:8443/svn/Tools/RunIE.bin repositories and attach results?

>

Thanks!
KIR


That is correct. Here's the info:

Path: MGW
URL: https://shiva:8443/svn/Tools/MGW
Repository Root: https://shiva:8443/svn/Tools/MGW
Repository UUID: dc0611af-9220-0410-9fa3-b8efaeeb6f02
Revision: 171
Node Kind: directory
Last Changed Author: LeIngInc
Last Changed Rev: 171
Last Changed Date: 2008-09-11 18:04:35 -0300 (Thu, 11 Sep 2008)

Path: RunIE.bin
URL: https://shiva:8443/svn/Tools/RunIE.bin
Repository Root: https://shiva:8443/svn/Tools/RunIE.bin
Repository UUID: dc0611af-9220-0410-9fa3-b8efaeeb6f02
Revision: 6
Node Kind: directory
Last Changed Author: melkor
Last Changed Rev: 6
Last Changed Date: 2007-05-24 17:09:41 -0300 (Thu, 24 May 2007)


Thanks,
Pablo
--


The dodo is a bird that is almost decent by now.

Pablo Montilla
www.odyssey.com.uy

0

Hello Pablo,

I think I can see the reason for the problem. You have several different repositories, which share the same
Repository UUID: dc0611af-9220-0410-9fa3-b8efaeeb6f02

From TeamCity's point of view (and from subversion's view) this UUID allows to differentiate one repository from another one:
http://svnbook.red-bean.com/en/1.1/re55.html .

When TeamCity observes that two repositories have the same UUID, it assumes they share the same repository revision
(and that they are, well, the same).

Looks like you use copy operation to create one repository from another, and this is illegal.

As a workaround, please try to make SVN repository UUID unique. This uuid is stored under db/uuid file in subversion repository
(but most likely, you'll have to re-checkout working copies for this repository).

Hope this helps,
KIR

0

On Mon, 15 Sep 2008 11:54:02 -0300, Kirill Maximov (JetBrains)
<no_reply@jetbrains.com> wrote:

Hello Pablo,

>

I think I can see the reason for the problem. You have several
different repositories, which share the same
Repository UUID: dc0611af-9220-0410-9fa3-b8efaeeb6f02

>

From TeamCity's point of view (and from subversion's view) this UUID
allows to differentiate one repository from another one:
http://svnbook.red-bean.com/en/1.1/re55.html .

>

When TeamCity observes that two repositories have the same UUID, it
assumes they share the same repository revision
(and that they are, well, the same).

>

Looks like you use copy operation to create one repository from
another, and this is illegal.

>

As a workaround, please try to make SVN repository UUID unique. This
uuid is stored under db/uuid file in subversion repository
(but most likely, you'll have to re-checkout working copies for this
repository).

>

Hope this helps,
KIR


Aha! That makes sense. We did that for some projects, using a template
project directory. I'll fix our projects.

Is it possible that the previous TC build didn't used the uuids? I'm sure
we didn't have this problem before...

Many, many thanks,
Pablo

--


Words with a "k" in them are funny. If it doesn't have a "k," it's not
funny.
-- Neil Simon

Pablo Montilla
www.odyssey.com.uy

0

Is it possible that the previous TC build didn't used the uuids? I'm sure
we didn't have this problem before...


We've made some changes in SVN support to eliminate the need to synchronize time
between TeamCity server and Subversion server. Now we use svn revision number as
TeamCity's revision number internally, but only for main svn repository and for externals
which reference the same repository (and we use date-based revision number for other externals).

So when we see an external with same UUID as the main repository, we assume that this external
has the revision number of main repository - and we get exception for your particular case.

Kind regards,
KIR

0

On Tue, 16 Sep 2008 03:52:00 -0300, Kirill Maximov (JetBrains)
<no_reply@jetbrains.com> wrote:

>

So when we see an external with same UUID as the main repository, we
assume that this external
has the revision number of main repository - and we get exception for
your particular case.

>

Kind regards,
KIR


OK, great to know. Many thanks for your help =)

Pablo

--


The secret of life is.... )&%Fe@1+=>/x.\#g. NO CARRIER

Pablo Montilla
www.odyssey.com.uy

0

Please sign in to leave a comment.