The Forks page for a Subversion Repository is missing

Support
1

I assume this feature should be available because the forks link is shown for my repository. The linked URL gets an HTTP 404 error. Refreshing does not change anything. Git and Hg repositories show their forks page without any problem. I get the same result as the repository owner and as the super admin.

I also note that the Subversion repository does not have a link for Pull Requests. Is there a limitation for Subversion repositories that is documented somewhere, or should the expectation be that the review functionality works regardless of the repository type?

My rcstack Rhodecode stack is on version 4.28.0.REL.2023.04.05.1

Thank you,
Brian

2

Hi Brian,

SVN doesn’t have working forks options because there’s no support of forking (as a concept of DVCS) for subversion.

Forks in subversion are basically branches.

3

How about pull requests? The docs say a PR can be from a fork or a branch, but I cannot access the Pull Requests feature for subversion. The features page mentions that code review works for all three repository types. Is the PR also something that cannot be supported with subversion?

Is there a features matrix that identifies how the different repository types interact differently with RhodeCode?

Thanks,
Brian

4

So, it is my understanding that, for Subversion, the code review process is left up to the users to implement the results of an approved or rejected commit. No PR to approve that gets merged; a rejected commit stays where it is and just shows a red mark on the web site to indicate that somebody should either roll it back if it is a commit to trunk or be sure to not merge it into trunk if it is on a branch. Is this correct?

5

Hi Brian,

sorry for late reply. So yes there are few levels of a code-review in rhodecode.

  • From most advance pull-requests based when you discuss a merge proposal (that works only for git and mercurial, since there’s no such concept of multi-commit code merge)

  • 2nd layer is from compare view when you can see combined diff for several commits and bulk reject/approve them as a unit of work

  • 3rd layer is commit-by-commit review for each individual change.

the 2 and 3 works also for SVN. So idea behind this is exactly something like you descibe. You have a review repository for SVN where all commits land, and those can be reviewed and marked as rejected/approved. Then those commits can be either rejected or approved by commiting then to the master repo.

Hope this helps.

1 Like