Am I correct in thinking that if I set the following:
ExcludePath = *.cs
All of the .cs files in the repo will be excluded from the mirror from now on?
Thus the mirror’s performance would improve for us?
If I wanted to exclude multiple options which of these would be the recommended way?
ExcludePath = *.cs, *.html
ExcludePath = *.cs
ExcludePath = *.html
you are completely right, the
excludePath = *.cs is a recursive pattern that would exclude the paths conforming to the patterns everywhere in the repository. As for the multiple options, the correct way to configure it is the latter one:
excludePath = *.cs
excludePath = *.html
So, in this case it would stop .cs files being mirrored from now and leave them as they are?
Are there any other affects?
Would I have to stop and restart the mirror?
Is there any way of estimating the performance difference before I do it?
Yes, after an
excludePath setting is applied, the path are excluded from the mirroring and thus are not being updated anymore, but not removed from the repository. To apply the setting you would need to run the
install command against the repository:
subgit install <REPO>
it will stop the daemon and start it again with the new settings.
I’m afraid, there is not want to estimate the performance.
If there is an issue and I remove the exclude line will the cs files be mirrored again without an issue?
Does this option exclude both git to svn or both ways?
excludePath option exclude a path from mirroring completely, so that neither changes made to those paths in SVN are being mirrored to Git, nor the opposite direction changes, those counterparts live completely on their own. As for the removing these settings – I’m afraid removing an
excludePath option is not that easy as add it, the removing will require a repository rebuild to be applied.
Thanks. So if we exclude all of the .cs files we should see a performance improvement of some kind even if we are just using the mirror to send git changes to svn?
Will it need a full rebuild of everything or just the files that were excluded?
It will need to rebuild everything, not only the excluded files. As for the performance – if there are plenty of the *.cs files that are being changed constantly, then of course the performance will be improved, yet it’s hard to tell in what degree – if the main performance issue is the data exchange between Git and SVN, then probably it will be significant improvement. Could you please share some more details on what the performance issue is?
When we create new merge requests in gitlab it takes almost a minute to create it. The time seems to be spent in the mirror. We are pruning unused branches (of which there are many) but I was looking at other ways to improve performance.
as far as I remember, that issue was mostly caused by high number of references the repository which caused long references check and for that issue the solution is to reduce number of references and/or pack the rest. Excluding some files from mirroring will definitely improve the performance, too, just because it will reduce the traffic and in some cases will even not trigger the synchronisation (in case when only excluded file are in the new commit), but I don’t think it will be significant affect to the performance unless there are plenty of files changed in such a merge request, or course.
Yes you are correct. That is our situation. I am currently working through our existing branches working out which ones we can delete but I was wondering whether this might provide a performance boost too.
We have a lot of commits but I am not sure how many files are changed on average