Unable to index subversion repository

Denis Cabasson August 21, 2013

Just installed the latest version of the plugin (v3.2.1) after an upgrade from JIRA 5.1 to 6.0.

I used to use an old version of the Atlassian SVN plugin (0.10.10 something).

Migration of most of the repositories worked fine, except for the ones that are actually using SVNBridge (from TFS).

Those are marked as inactive, with the error :

Inactive (svn: E204900: Referential integrity constraint violation: "COPY_FROM_REVISION_FK: CACHE.COPIES FOREIGN KEY(REPOID, FROM_REVISION) REFERENCES CACHE.REVISIONS(REPOID, REVISION) (5, 257146)"; SQL statement: insert into CACHE.COPIES (REVISION,ITEMID,FROM_REVISION, FROM_ITEMID, REPOID) VALUES(?,?,?,?,?) [23506-173])

I have tried stopping the plugin / deleting cache from disk / restarting the plugin, but it just goes and merily index the SvnBridge repository, until it dies with that error.

Thanks!

5 answers

1 vote
Kinto Soft
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 21, 2013

I have access only to a portion of the repository

Yes, it looks a very good reason. Indexing the full history is strongly recommende but it's not a must. The problem in your case is that some artifacts are crossing the borderline between the privileged and non-privileged areas and Subversion Plus is tremendously strict.

How could I find the latest indexed revision since it's not appearing in my admin panel?

Maybe it has not much sense becaue the above. But if you are interested you can get it by running this query:

select max(revision) from CACHE.REVISIONS where repoId=5;

Denis Cabasson August 27, 2013

I have requested full read access to the repository, but haven't heard back yet. Your answer makes sense. Coudl subversion plus degrade a little more gracefully, like by ignoring copies that cross this boundary? Is it fair to assume that everybody will always have access to the whole repository, as opposed to a portion of it?

Norman Abramovitz
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 27, 2013

The subversion indexer has its own separate login to subversion. It does make sense that this special user has read access to the complete respository since it can process anything in that respository. In your case it needs access to any part of the tree that was copied into your projects.

Kinto Soft
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 27, 2013

Is it fair to assume that everybody will always have access to the whole repository, as opposed to a portion of it?

It's not fair. But there is a sutil difference among the whole repository and the project dependencies.

For example, a customer might create a branch in order to a 3rd party consulting company to develop a software project. How is that branch created?

If the project is new, the customer will directly create a new branch without any dependency, therefore Subversion Plus could index that portion of the repository without any problem.

If the project is a derivation of the existing one... then the cusomer would create a branch by copying the project from somewhere. If the customer provides access to read the original project (not the whole repository is required), there is not any problem. But if the company hides the history of the project... is that fair?

Does the mentioned above match your case?

Kinto Soft
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 27, 2013

Regarding the first part of the question:

Coudl subversion plus degrade a little more gracefully, like by ignoring copies that cross this boundary?

Probably yes, but I still have to analyze it in more detail. It is not a bad idea as it would allow to use Subversion Plus even in these cases.

In the meanwhile you might want to drop the constraint from table at your own risk. This would allow to index the whole repository though you could get some unexpected results.

I never tried it:

ALTER TABLE CACHE.COPIES DROP CONSTRAINT COPY_FROM_REVISION_FK;

Interesting ;)

0 votes
Denis Cabasson August 21, 2013

Hey Pablo, and thanks for the answer. Unfortunately, there is no information about the revisions :

Other than that, it seems the current revision of this repository is 257724.

How could I find the latest indexed revision since it's not appearing in my admin panel?

0 votes
Denis Cabasson August 21, 2013

After reading further your reply, Pablo, I think this might stem from the fact that I have access only to a portion of the repository. Technically, I could have access to a copy, but not to its source. I will try to get a read access to the whole repository and see if that solves those issues.

0 votes
Denis Cabasson August 21, 2013

Hey Pablo, and thanks for the answer. Unfortunately, there is no information about the revisions :

Other than that, it seems the current revision of this repository is 257724.

How could I find the latest indexed revision since it's not appearing in my admin panel?

0 votes
Kinto Soft
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 21, 2013

The error means that the SVNBridge API is returning the result of a svn copy command of a branch created from the revision 257146 to somewhere in the repo ID=5, but the revision 257146 is not yet indexed. It should not happen as a copied path can never be younger that its parent (regarding the revision number).

Please, look at the latest revision indexed for the repository ID=5 from the repositories list at the bottom of the plugin configuration page. You can see the progress there: latest indexed revision / total revisions in the repository. Then the revision origin of the problem would be the latest indexed revision + 1. It should be < 257146.

Look at the history log of latest indexed revision + 1 by using a Subversion client and look for some path copied from... 257146!. Does it exist?

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events