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.
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;
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?
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.
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?
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;
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?
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.
Atlas Camp is our developer event which will take place in Barcelona, Spain from the 6th -7th of September . This is a great opportunity to meet other developers and get n...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG