Large vs. single-day files for resources #2524
-
|
Hi everyone, Thanks for the answer, have a nice day! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
Probably the first reason is historical: that's how Laszlo set up the project. Beyond this, I think it works well with source control. There are multiple contributors submitting pull requests to merge into the main repository. When the changes are to different files, the pull requests can be merged automatically. If there were only a few files, changes to the same file would be more common, and manual intervention to resolve merge conflicts would be necessary more often, either on the part of those who submit pull requests or on the part of those who merge them. When I merge changes from this repository into my fork, I can easily see from the list of filenames where changes are being made. It is probably also faster to not have to parse all the offices of a year in order to generate the text for one Mass or canonical hour. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the answer. Yes, in the case of calendar and proper texts and psalm, I do get it and find it practical. However in the case of Martyrology or Rule, I find it a bit impractical. In our monastery, we use a different division of the rule, that turns it around only three times during the year, instead of four times, which is used here, and in order to adjust for it, I'd have to either edit about 200 small files, or simply write another routine, which is what I did. Ditto in Martyrology or Necrology. But the truth is that it makes the programming easier. |
Beta Was this translation helpful? Give feedback.
-
|
Another advantage of this division, at least for the propers, is that it makes it easy to change a feast when you have a special calendar (for a congregation, for example). |
Beta Was this translation helpful? Give feedback.
-
|
Yes, for the Calendar, I completely get it. And it's so much easier than say a sql database, of course :-) |
Beta Was this translation helpful? Give feedback.
Probably the first reason is historical: that's how Laszlo set up the project.
Beyond this, I think it works well with source control. There are multiple contributors submitting pull requests to merge into the main repository. When the changes are to different files, the pull requests can be merged automatically. If there were only a few files, changes to the same file would be more common, and manual intervention to resolve merge conflicts would be necessary more often, either on the part of those who submit pull requests or on the part of those who merge them.
When I merge changes from this repository into my fork, I can easily see from the list of filenames where changes are being made.
…