Authors:
Ulvi Shakikhanli Doctoral School of Computer Science, Faculty of Science and Informatics, University of Szeged, Szeged, Hungary

Search for other papers by Ulvi Shakikhanli in
Current site
Google Scholar
PubMed
Close
and
Vilmos Bilicki Doctoral School of Computer Science, Faculty of Science and Informatics, University of Szeged, Szeged, Hungary

Search for other papers by Vilmos Bilicki in
Current site
Google Scholar
PubMed
Close
https://orcid.org/0000-0002-7793-2661
Open access

Abstract

The comparison of Mono and Multi Repository structures is a highly debated topic in the software development field. Despite the choice of repository structure is the first main step in development; so far, this comparison has only been made on a small or local scale. Here, Mono and Multi Repository structures have been compared from different aspects using thousands of projects.

First, an algorithm shared for collecting and identifying Mono and Multi Repository projects and save them into the database. Database was used for making different comparisons for example the usage intensity of both structure types over time, the developer's preference over structure type based on their country and so on. Also, all these comparisons have been made according to the team size and development period for each repository structure.

Abstract

The comparison of Mono and Multi Repository structures is a highly debated topic in the software development field. Despite the choice of repository structure is the first main step in development; so far, this comparison has only been made on a small or local scale. Here, Mono and Multi Repository structures have been compared from different aspects using thousands of projects.

First, an algorithm shared for collecting and identifying Mono and Multi Repository projects and save them into the database. Database was used for making different comparisons for example the usage intensity of both structure types over time, the developer's preference over structure type based on their country and so on. Also, all these comparisons have been made according to the team size and development period for each repository structure.

1 Introduction

Development area and information technologies are improving every day. It is all too common for developers to start coding an application without a formal architecture in place [1]. In general, this creates some problems for developers and others in this field for example sometimes certain things as the architecture of application can cause some confusion. It is well known that software design and architectural patterns are general and reusable solutions to the problems, like computer hardware performance limitations, high availability and minimization of business risk [2]. For the sake of clarity, it can be stated that the architectural pattern is a solution that is directed to elements of software architecture. However, there are no patterns for managing the architecture of large projects at the repository level. There are several Version Control Software Systems (VCSSs) and all of them have different characteristics. Some of them are free (for example: Git, Fossil, Mercurial) and they support several features that may be crucial during the version control process [3]. Beside this, several repository structures have appeared since 2009 like Monorepo (also called Mono Repository), Multirepo (also known as Multi Repository or Polyrepo); and the latest architecture, which can be understood as a hybrid of the previous two is Metarepo (also called Meta Repository) [4].

Choosing repository structure is the first step for development period and can be accepted as the foundation of whole project. Since each repository structure has its own features this choice is highly crucial.

Based on the research it has become clear that some of the big companies choose different approaches for their own software projects. In some cases the reason for them choosing a certain repository structure depends on the type of culture they prefer. For instance, Netflix uses the Multi Repository architecture because of its culture called “freedom and responsibility” [5]. There are also other big companies that prefer the Mono Repository approach like Microsoft and it also can be stated that its repository is one of the biggest one [6].

The precise definition of Mono and Multi Repository projects is hotly debated but simple definitions will be provided by using current blogs and some academic papers written in this area.

The Mono Repository (Monorepo or Single Repository) is a type of source control pattern where all the components and sections of source code are kept in one repository. And the Multi Repository pattern manages all the packages and source code components in several repositories [7].

There are two key differences between this paper and the others. First of all the comparison was made from different perspectives that are not properly covered or sometimes not even mentioned in the literature. The second, the comparisons did not done on a basis of projects of some specific company or group of developers. The database [8] was created by us and it contains projects gathered from all over the world. These projects vary from small one developer start-up projects to big commercial ones and it allows us to make a comparison on a much bigger scale than has never been attempted before.

Several questions prepared to make comparisons more understandable and they will be stated later on.

2 Methodology

This chapter presents research methodology, the key questions, algorithm and approaches used in the study.

2.1 Research questions

The main aim of this paper is to compare two basic repository structures and verify them according to the different measures. In order to make the paper clearer and more understandable, the following five questions were defined:

  • RQ #1. How does the literature compare the Mono/Multi Repository structure?

  • RQ #2. What is the usage intensity of the Mono and Multi Repository approaches?

  • RQ #3. Is there any relationship between the developer's country and their choice of repo structure?

  • RQ #4. What is the connection between the team size and repository structure?

  • RQ #5. What is the connection between the development period and repository structure?

2.2 Literature review

Unfortunately, there is a shortage of academic studies that make a comparison between Mono and Multi Repository structures. This is why using the Multivocal Literature Review (MLR) was preferred to get the same basic understanding [9]. Therefore, it means that mostly different blogs were used and posts for the literature review. First, let us see what the literature says about the definition of Mono and Multi Repository systems.

The Mono Repository (Monorepo or Single Repository) is a type of source control pattern where all the components and sections of source code are kept in one repository. In contrast, the Multi Repository pattern manages all packages and source code components in several repositories [7].

2.2.1 Accessibility (visibility)

The well-organized hierarchical structure is the main advantage of Mono Repository structure [4]. In this case, it had to be assumed that all the developers have access to all parts of the project (of course this may not so depending on the company policy). The Survey conducted among Google developers can shed light on this case [10]. It told us that most developers greatly value the visibility and access possibilities in different parts of the code, but this is also possible in a Multi Repository approach. The main reason for this is that developers can check the effect and workflow of different components in the repository and gain an overall understanding of the project this way. However, as it was shown in the survey, all of these benefits may become drawbacks in some cases and create problems in the Multi Repository architecture. One of these might be dependency problems. In big companies like Google, the size of Mono Repository projects may be enormous (e.g., 2 billion lines of code) and changing one dependency in a project can cause huge difficulties like the diamond dependency.

2.2.2 Testing for security and functionality

This may be one of the best advantages of the Multi Repository structure. Independent repositories allow isolated testing for module security and functionality [11]. Nevertheless, with this type of flexibility it also introduces complexity during version control and this usually creates some drawbacks.

2.3 Identifying and collecting Mono Repository projects

Collecting Mono Repository projects is not as easy as the Multi Repository one, so that is why it is going to be discussed first. First, it had to be mentioned that the Github platform was used as source of finding project. Github is a free version control system, which contains millions of projects so it is something like a gold mine for this type of software research. Before dive in the steps of algorithm it had be mentioned that in order to be able to compare the collected results and check accuracy of algorithm. Several Mono and Multi Repository projects have been collected from different resources to be used as examples. Those projects were chosen according to the definition of structure types.

The whole procedure of identifying and collecting Mono Repository projects can be separated into three parts:

  1. Get a list of possible users;

  2. Check each repository of user;

  3. Add newly founded projects to the database.

2.3.1 Get a list of possible users

Github Application Programming Interface (API) can provide us with JavaScript Object Notation (JSON) documents. Those documents contain several parameters of repositories. As it was mentioned previously, Github has millions of users and it is not possible just try to get any list of users. In this case, it is needed to find those users that may have mono or multi repository projects. There are also some additional steps for user selection. Users are excluded from the list if it has no repositories or repositories don't belong any of the structures.

2.3.2 Check each repository of a user

This section is about how to identify Mono Repository projects in Github user accounts.

In order to be able to understand this part the definition of a mono repository project had to be remembered. Earlier it was said that a Mono Repository project should contain all parts of the project in one folder or repository.

An algorithm had to be constructed to define a repository that is either a mono or not. The file structure of the repository was used for this. The file structure is a list of names of folders and files in a repository. These are folder names and they may be listed like “Client, Server, UI, Front, Back, API, Frontend, and Backend”.

As it might be expected, these are names of folders, which contain components of either the frontend or the backend parts of the project.

The steps of algorithm are:

  • Step 1: Find the repository of the user;

  • Step 2: Collect the name of folders of the repository;

  • Step 3: Compare the collected folder names with the previously defined list;

  • Step 4: Add the project to the database if there are any matches.

Here it should be mentioned that Step 3 is the most important part and it can be carried out in several ways depending on the programming language and framework.

2.3.3 Add the newly founded project to the database

This is the last step. Unique database has been created for this research. There are several features of the repository that can be added to the database depending on the requirement. In addition, of course all these features can be obtained by the Github API if the name of the repository and the user is known.

2.4 Identifying and collecting Multi Repository projects

It had already been remarked that the collection and identification process of the mono and multi repository projects is quite similar. Steps below show the shows the flow of procedure.

  1. Get a list of possible users;

  2. Collect properties of each repository;

  3. Match the repositories;

  4. Add newly founded projects to the database.

The first step is almost the same so there is no need to explain them again. Let us now go directly to the third step.

2.4.1 Collect properties of each repository

As it had already been said, one can get all the properties of repository using the Github API. In this stage, a simple database will be created for users and add all the repositories with their main properties to this database. Main properties can be listed as follow: name, created and finished date, database used and so on.

2.4.2 Match the repositories

This stage is probably one of the most difficult and time-consuming part of this study. Therefore, after collecting all the repositories of a particular user, there are two main questions:

  • Q1: How frontend and backend repositories can be identified and grouped?

  • Q2: How to define which frontend and backend repositories belong to the same project?

The Machine Learning (ML) algorithm based on the file structure of the repository provides the answer for the first question. ML models trained based on thousands of repositories and it can define the type of repository with almost 90% accuracy.

The repository sets which are demonstrated here can be seen as rough sets [12]. So the answer of the second question lies with classification. After the first stage, repositories divided into two groups, the frontend and backend repositories. Repositories in those two groups have been classified using K Nearest Neighbor (KNN) method based on the name of the repository and content of the readme file. After lots of tests and measurements, an accuracy score of nearly 90% acquired. For a better understanding of this stage, tests can be presented as follows:

The database contains several features of the repository (“Name of repository”, “Created date”, etc.). The main idea was to apply these features and make a classification based on them. Since variations can be endless, it was extremely hard to find the right features. In order to do this, several approaches have been tried out and most of them abandoned. For reasons of space, results of those tests are presented in Table 1.

Table 1.

The success rate of different feature combinations

Used features Success rate
RN + L + F + DT + D + FS + R 36%
RN + L + F +DT + D + FS 32%
RN + L + F + DT + D +R 48%
RN + L + F + D + R 48%
RN + L + F + R 52%
RN + L + R 56%
RN + R 89%
RN + L 28%
RN + L + F 24%

Table 2 shows us the list of abbreviations while Table 1 explaining results of tests. As it can be seen in Table 1, all the important features were utilized in the database and the success rate was reasonably low. In the second case, “Readme” was removed, the result also fell with it, and of course, it increased again when it included it. As it might be expected, the number of combinations may be several hundred. This is why there is no need to include all of them here. The highest score was obtained when “Repository Name” and “Readme” were used together. In this test, it was nearly 89%, but depending on the test subject, it may plus or minus five percent. The utility of the algorithm lies not only in its accuracy, but also with it being most probably the only algorithm and this may be one of the main steps for matching front and backend repositories.

Table 2.

List of abbreviations

Name of feature Abbreviation of it
Repo Name RN
Language L
Framework F
Database type DT
Developers D
File structure FS
Readme R

3 A comparison of the mono and multi repository approaches

This section answers to the questions RQ #2 - RQ #5 from different aspects. In order to be able to get a better insight specific group of projects that are called “Big Projects” were used. For the sake of simplicity, these projects have been classified in a 3-month development period and used 10 Mbytes of memory.

3.1 An intensity comparison of the repository structure

Now, the usage level of the repository structure was described over time from 2015 to 2021 and address RQ #2. The whole database was utilized (including Big Projects) to get better results. As it can be seen in Fig. 1, the multi repository approach became popular from 2017.

Fig. 1.
Fig. 1.

The usage level of repository structure by years

Citation: Pollack Periodica 2022; 10.1556/606.2022.00526

The Multi Repository approach practically did not exist in 2015 and it started to become popular and rival the Mono Repository approach in 2018. Surprisingly, the Multi Repository approach got a huge boost in 2019 and afterwards the Mono Repository approach was never quite able to catch up. Therefore, it means the Multi Repository approach is much more popular than the Mono Repository one, but this does not mean that there is no need to compare both approaches.

3.1.1 A comparison of the developer countries and the structure type

Firstly, Fig. 2 provides some rather interesting results. It quickly gives us the answer to RQ #3. As it can be seen, the Multi Repository approach is quite popular in almost all the major countries but there are notable exceptions. For example, while the number of developers from China is not only much bigger than the others, they also have the highest percentage of Mono Repository choices. Here, it can be observed that the choice of repository structure is not just based on company policy but also on the “programming culture” of the given country.

Fig. 2.
Fig. 2.

The countries of developers for each structure type

Citation: Pollack Periodica 2022; 10.1556/606.2022.00526

3.1.2 A comparison of the team size in Mono/Multi Repository structures

The aim of this section is to answer RQ #4. Before examining this comparison again there are a few things, which need to be mentioned. In order to be able to get good results the projects with fewer than five developers were eliminated because this type of projects are mostly for personal use and they do not have any real commercial value.

The projects with a team size of between 5 and 10 developers were compared in Fig. 3. Here, the results indicate that the Multi Repository approach has the upper hand. Despite this, the share of Multi Repository projects starts to decrease when the team size increases. Hence, it can be said that developer teams with a bigger size prefer to work on the Mono Repository structure rather than the Multi one.

Fig. 3.
Fig. 3.

A comparison of the team size

Citation: Pollack Periodica 2022; 10.1556/606.2022.00526

3.1.3 A comparison of the development period

With the last comparison, RQ #5 was answered. Figure 4 tells us the percentage of development period for each approach based on the whole database. For example, in Fig. 4a it can be observed that almost 64% of all the Mono Repository projects are completed in under a month and this figure is nearly 66% for Multi Repository cases. Moreover, figures for other cases like the development period between 3 and 6 months and over 12 months were practically the same Fig. 4b. It is again worth to remind that these pie charts were created based on the whole database.

Fig. 4.
Fig. 4.

The development period in terms of two approaches used, a) Mono Repository, b) Multi Repository

Citation: Pollack Periodica 2022; 10.1556/606.2022.00526

In Fig. 5 the Big Projects were examined, which have been mentioned earlier took up 10 Mb of memory and the development period was over 3 months. In the previous case, the whole database was examined and it appeared that the percentage values were closer to each other and now surprisingly similar values can be observed here as well.

Fig. 5.
Fig. 5.

The development period comparison of two approaches (Big Projects), a) Mono Repository, b) Multi Repository

Citation: Pollack Periodica 2022; 10.1556/606.2022.00526

Naturally, there are some differences but they are no more than 3% and can be ignored. Based on the results, it can be hypothesized that the repository structure of the project does not significantly affect the development period. Of course, while more comparisons are required to test this statement, it does show that some interesting results could be acquired by examining real projects carried out by different developer teams.

4 Conclusion

In this study, followings were presented

  1. a) A comparison of two repository structure types from quite different perspectives using databases containing different types of projects;
  2. b) A unique algorithm for identifying and collecting mono and multi repository projects from Github;
  3. c) Databases were created with the help of this method and they can be used by other researchers for different purposes.

Regarding a), most of the comparisons between Mono and Multi Repository approaches were made using rather small or local scales. Related papers, which were found in the literature, focused only projects of one company or a specific group of developers. Here, new approach implemented to this comparison by using a new database that contains projects taken from different backgrounds. This way the resulting comparisons were much more general and produced some things that were never taken into account in similar studies. According to the results it can be said that Multi Repository projects takes less time than Mono Repository ones and additionally the team sizes in Mono Repository projects are much bigger than Multi one. Beside these choice of structure compared according to the regions of developers and that can be useful for project planners when they want to take regions of developers in account.

Regarding b), the procedure of identifying a Mono Repository project is based on its file structure. As it was mentioned, in the definition all, the components of the project are kept in one repository and obviously, they were inside specific folders. They can easily be defined by examining the file structure. The identification of multi repository projects was based on clustering algorithms. In this algorithm, the name and the content of the readme file of the repository were used. Later only needed to use Github API commands to collect the specific features of projects and repositories present in the database.

Regarding c), database was created that can be used for different purposes and in this paper; the difference between two repository structures was tried to ascertain. At first, the degree of usage of the repository structure from 2015 to 2021 was checked. Secondly, the effects of structures were compared based on aspects like development period, number of developers in the team and regions of developers.

There are several ways two repository structures can be composed but almost all of them are based on views of developers and some statistics prepared for certain companies (like Google and Facebook). In this study, not only a way was proposed for identifying and collecting mono and multi repository projects, but also created a unique database to go with it. . Other researchers can do additional comparisons according to the database.

Plans for future work include the following. Now, the algorithm does not work on specific types of projects and it needs to be extended it to get results that are more objective. In addition, there is plans for creating metrics for each repository structure and after that, it would be possible to get a clearer view of how the two different repository structures can affect the development period

References

  • [1]

    Comparison of version-control software, Wikipedia , 2019. [Online]. Available: https://en.wikipedia.org/wiki/Comparison_of_version-control_software. Accessed: Dec. 6, 2021.

  • [2]

    G. Kokrehel and V. Bilicki , “The impact of the software architecture on the developer productivity,” Pollack Period., vol. 17, no. 1, pp. 711, 2022.

    • Crossref
    • Search Google Scholar
    • Export Citation
  • [3]

    Architectural pattern, Wikipedia, 2021. [Online]. Available: https://en.wikipedia.org/wiki/Architectural_pattern. Accessed: Nov. 25, 2021.

    • Search Google Scholar
    • Export Citation
  • [4]

    B. Libbey , Monorepo, Manyrepo, Metarepo, 2019. [Online]. Available: https://notes.burke.libbey.me/metarepo/. Accessed: Nov. 1, 2021.

  • [5]

    R. Hastings , Netflix culture: Freedom & responsibility, Reed Hastings. Slideshare 2019. [Online] Available: https://www.slideshare.net/reed2001/culture-1798664/2-Netflix_CultureFreedom_Responsibility2. Accessed: Nov. 15, 2021.

    • Search Google Scholar
    • Export Citation
  • [6]

    H. Brian , Scaling Git (and some back story), Microsoft Devblocks, 2017. [Online]. Available: https://devblogs.microsoft.com/bharry/scaling-git-and-some-back-story/. Accessed: Nov. 15, 2021.

    • Search Google Scholar
    • Export Citation
  • [7]

    P. L. Scott , Mono-repo or multi-repo? Why choose one, when you can have both? Medium.com, 2017. [Online]. Available: https://patrickleet.medium.com/mono-repo-or-multi-repo-why-choose-one-when-you-can-have-both-e9c77bd0c668. Accessed: Oct. 4, 2021.

    • Search Google Scholar
    • Export Citation
  • [8]

    Multi/Mono Repository Database, Github 2021. [Online]. Available: https://github.com/Shakikhanli/Mono-Multi-Repository-Database. Accessed: Dec. 10, 2021.

    • Search Google Scholar
    • Export Citation
  • [9]

    R. T. Ogawa and B. Malen , “Towards rigor in reviews of multivocal literatures: Applying the exploratory case study method,” Rev. Educ. Res., vol. 61, no. 3, pp. 265286, 1991.

    • Crossref
    • Search Google Scholar
    • Export Citation
  • [10]

    C. Jaspan , M. Jorde , A. Knight , C. Sadowski , E. K. Smith , C. Winter , and E. Murphy-Hill , “Advantages and disadvantages of a Monolithic Repository: A case study at Google,” in Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice, Gothenburg, Sweden, May 27–June 3, 2018, pp. 225234.

    • Crossref
    • Search Google Scholar
    • Export Citation
  • [11]

    T. Holmes , Terraform mono repo vs. multi repo: The great debate, Hashi Corp. [Online]. Available: https://www.hashicorp.com/blog/terraform-mono-repo-vs-multi-repo-the-great-debate. Accessed: Jan. 28, 2021.

    • Search Google Scholar
    • Export Citation
  • [12]

    D. Nagy , T. Mihálydeák , and L. Aszalós , “Graph approximation on similarity based rough sets,” Pollack Period., vol. 15, no. 2, pp. 2536, 2020.

    • Crossref
    • Search Google Scholar
    • Export Citation
  • [1]

    Comparison of version-control software, Wikipedia , 2019. [Online]. Available: https://en.wikipedia.org/wiki/Comparison_of_version-control_software. Accessed: Dec. 6, 2021.

  • [2]

    G. Kokrehel and V. Bilicki , “The impact of the software architecture on the developer productivity,” Pollack Period., vol. 17, no. 1, pp. 711, 2022.

    • Crossref
    • Search Google Scholar
    • Export Citation
  • [3]

    Architectural pattern, Wikipedia, 2021. [Online]. Available: https://en.wikipedia.org/wiki/Architectural_pattern. Accessed: Nov. 25, 2021.

    • Search Google Scholar
    • Export Citation
  • [4]

    B. Libbey , Monorepo, Manyrepo, Metarepo, 2019. [Online]. Available: https://notes.burke.libbey.me/metarepo/. Accessed: Nov. 1, 2021.

  • [5]

    R. Hastings , Netflix culture: Freedom & responsibility, Reed Hastings. Slideshare 2019. [Online] Available: https://www.slideshare.net/reed2001/culture-1798664/2-Netflix_CultureFreedom_Responsibility2. Accessed: Nov. 15, 2021.

    • Search Google Scholar
    • Export Citation
  • [6]

    H. Brian , Scaling Git (and some back story), Microsoft Devblocks, 2017. [Online]. Available: https://devblogs.microsoft.com/bharry/scaling-git-and-some-back-story/. Accessed: Nov. 15, 2021.

    • Search Google Scholar
    • Export Citation
  • [7]

    P. L. Scott , Mono-repo or multi-repo? Why choose one, when you can have both? Medium.com, 2017. [Online]. Available: https://patrickleet.medium.com/mono-repo-or-multi-repo-why-choose-one-when-you-can-have-both-e9c77bd0c668. Accessed: Oct. 4, 2021.

    • Search Google Scholar
    • Export Citation
  • [8]

    Multi/Mono Repository Database, Github 2021. [Online]. Available: https://github.com/Shakikhanli/Mono-Multi-Repository-Database. Accessed: Dec. 10, 2021.

    • Search Google Scholar
    • Export Citation
  • [9]

    R. T. Ogawa and B. Malen , “Towards rigor in reviews of multivocal literatures: Applying the exploratory case study method,” Rev. Educ. Res., vol. 61, no. 3, pp. 265286, 1991.

    • Crossref
    • Search Google Scholar
    • Export Citation
  • [10]

    C. Jaspan , M. Jorde , A. Knight , C. Sadowski , E. K. Smith , C. Winter , and E. Murphy-Hill , “Advantages and disadvantages of a Monolithic Repository: A case study at Google,” in Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice, Gothenburg, Sweden, May 27–June 3, 2018, pp. 225234.

    • Crossref
    • Search Google Scholar
    • Export Citation
  • [11]

    T. Holmes , Terraform mono repo vs. multi repo: The great debate, Hashi Corp. [Online]. Available: https://www.hashicorp.com/blog/terraform-mono-repo-vs-multi-repo-the-great-debate. Accessed: Jan. 28, 2021.

    • Search Google Scholar
    • Export Citation
  • [12]

    D. Nagy , T. Mihálydeák , and L. Aszalós , “Graph approximation on similarity based rough sets,” Pollack Period., vol. 15, no. 2, pp. 2536, 2020.

    • Crossref
    • Search Google Scholar
    • Export Citation
  • Collapse
  • Expand
  • Top
Submit Your Manuscript
 
The author instructions template is available in MS Word.
Please, download the file from HERE.

 

Senior editors

Editor(s)-in-Chief: Iványi, Amália

Editor(s)-in-Chief: Iványi, Péter

 

Scientific Secretary

Miklós M. Iványi

Editorial Board

  • Bálint Bachmann (Institute of Architecture, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Jeno Balogh (Department of Civil Engineering Technology, Metropolitan State University of Denver, Denver, Colorado, USA)
  • Radu Bancila (Department of Geotechnical Engineering and Terrestrial Communications Ways, Faculty of Civil Engineering and Architecture, “Politehnica” University Timisoara, Romania)
  • Charalambos C. Baniotopolous (Department of Civil Engineering, Chair of Sustainable Energy Systems, Director of Resilience Centre, School of Engineering, University of Birmingham, U.K.)
  • Oszkar Biro (Graz University of Technology, Institute of Fundamentals and Theory in Electrical Engineering, Austria)
  • Ágnes Borsos (Institute of Architecture, Department of Interior, Applied and Creative Design, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Matteo Bruggi (Dipartimento di Ingegneria Civile e Ambientale, Politecnico di Milano, Italy)
  • Petra Bujňáková (Department of Structures and Bridges, Faculty of Civil Engineering, University of Žilina, Slovakia)
  • Anikó Borbála Csébfalvi (Department of Civil Engineering, Institute of Smart Technology and Engineering, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Mirjana S. Devetaković (Faculty of Architecture, University of Belgrade, Serbia)
  • Szabolcs Fischer (Department of Transport Infrastructure and Water Resources Engineering, Faculty of Architerture, Civil Engineering and Transport Sciences Széchenyi István University, Győr, Hungary)
  • Radomir Folic (Department of Civil Engineering, Faculty of Technical Sciences, University of Novi Sad Serbia)
  • Jana Frankovská (Department of Geotechnics, Faculty of Civil Engineering, Slovak University of Technology in Bratislava, Slovakia)
  • János Gyergyák (Department of Architecture and Urban Planning, Institute of Architecture, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Kay Hameyer (Chair in Electromagnetic Energy Conversion, Institute of Electrical Machines, Faculty of Electrical Engineering and Information Technology, RWTH Aachen University, Germany)
  • Elena Helerea (Dept. of Electrical Engineering and Applied Physics, Faculty of Electrical Engineering and Computer Science, Transilvania University of Brasov, Romania)
  • Ákos Hutter (Department of Architecture and Urban Planning, Institute of Architecture, Faculty of Engineering and Information Technolgy, University of Pécs, Hungary)
  • Károly Jármai (Institute of Energy and Chemical Machinery, Faculty of Mechanical Engineering and Informatics, University of Miskolc, Hungary)
  • Teuta Jashari-Kajtazi (Department of Architecture, Faculty of Civil Engineering and Architecture, University of Prishtina, Kosovo)
  • Róbert Kersner (Department of Technical Informatics, Institute of Information and Electrical Technology, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Rita Kiss  (Biomechanical Cooperation Center, Faculty of Mechanical Engineering, Budapest University of Technology and Economics, Budapest, Hungary)
  • István Kistelegdi  (Department of Building Structures and Energy Design, Institute of Architecture, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Stanislav Kmeť (President of University Science Park TECHNICOM, Technical University of Kosice, Slovakia)
  • Imre Kocsis  (Department of Basic Engineering Research, Faculty of Engineering, University of Debrecen, Hungary)
  • László T. Kóczy (Department of Information Sciences, Faculty of Mechanical Engineering, Informatics and Electrical Engineering, University of Győr, Hungary)
  • Dražan Kozak (Faculty of Mechanical Engineering, Josip Juraj Strossmayer University of Osijek, Croatia)
  • György L. Kovács (Department of Technical Informatics, Institute of Information and Electrical Technology, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Balázs Géza Kövesdi (Department of Structural Engineering, Faculty of Civil Engineering, Budapest University of Engineering and Economics, Budapest, Hungary)
  • Tomáš Krejčí (Department of Mechanics, Faculty of Civil Engineering, Czech Technical University in Prague, Czech Republic)
  • Jaroslav Kruis (Department of Mechanics, Faculty of Civil Engineering, Czech Technical University in Prague, Czech Republic)
  • Miklós Kuczmann (Department of Automations, Faculty of Mechanical Engineering, Informatics and Electrical Engineering, Széchenyi István University, Győr, Hungary)
  • Tibor Kukai (Department of Engineering Studies, Institute of Smart Technology and Engineering, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Maria Jesus Lamela-Rey (Departamento de Construcción e Ingeniería de Fabricación, University of Oviedo, Spain)
  • János Lógó  (Department of Structural Mechanics, Faculty of Civil Engineering, Budapest University of Technology and Economics, Hungary)
  • Carmen Mihaela Lungoci (Faculty of Electrical Engineering and Computer Science, Universitatea Transilvania Brasov, Romania)
  • Frédéric Magoulés (Department of Mathematics and Informatics for Complex Systems, Centrale Supélec, Université Paris Saclay, France)
  • Gabriella Medvegy (Department of Interior, Applied and Creative Design, Institute of Architecture, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Tamás Molnár (Department of Visual Studies, Institute of Architecture, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Ferenc Orbán (Department of Mechanical Engineering, Institute of Smart Technology and Engineering, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Zoltán Orbán (Department of Civil Engineering, Institute of Smart Technology and Engineering, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Dmitrii Rachinskii (Department of Mathematical Sciences, The University of Texas at Dallas, Texas, USA)
  • Chro Radha (Chro Ali Hamaradha) (Sulaimani Polytechnic University, Technical College of Engineering, Department of City Planning, Kurdistan Region, Iraq)
  • Maurizio Repetto (Department of Energy “Galileo Ferraris”, Politecnico di Torino, Italy)
  • Zoltán Sári (Department of Technical Informatics, Institute of Information and Electrical Technology, Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Grzegorz Sierpiński (Department of Transport Systems and Traffic Engineering, Faculty of Transport, Silesian University of Technology, Katowice, Poland)
  • Zoltán Siménfalvi (Institute of Energy and Chemical Machinery, Faculty of Mechanical Engineering and Informatics, University of Miskolc, Hungary)
  • Andrej Šoltész (Department of Hydrology, Faculty of Civil Engineering, Slovak University of Technology in Bratislava, Slovakia)
  • Zsolt Szabó (Faculty of Information Technology and Bionics, Pázmány Péter Catholic University, Hungary)
  • Mykola Sysyn (Chair of Planning and Design of Railway Infrastructure, Institute of Railway Systems and Public Transport, Technical University of Dresden, Germany)
  • András Timár (Faculty of Engineering and Information Technology, University of Pécs, Hungary)
  • Barry H. V. Topping (Heriot-Watt University, UK, Faculty of Engineering and Information Technology, University of Pécs, Hungary)

POLLACK PERIODICA
Pollack Mihály Faculty of Engineering
Institute: University of Pécs
Address: Boszorkány utca 2. H–7624 Pécs, Hungary
Phone/Fax: (36 72) 503 650

E-mail: peter.ivanyi@mik.pte.hu 

or amalia.ivanyi@mik.pte.hu

Indexing and Abstracting Services:

  • SCOPUS

 

2021  
Web of Science  
Total Cites
WoS
not indexed
Journal Impact Factor not indexed
Rank by Impact Factor

not indexed

Impact Factor
without
Journal Self Cites
not indexed
5 Year
Impact Factor
not indexed
Journal Citation Indicator not indexed
Rank by Journal Citation Indicator

not indexed

Scimago  
Scimago
H-index
12
Scimago
Journal Rank
0,26
Scimago Quartile Score Civil and Structural Engineering (Q3)
Materials Science (miscellaneous) (Q3)
Computer Science Applications (Q4)
Modeling and Simulation (Q4)
Software (Q4)
Scopus  
Scopus
Cite Score
1,5
Scopus
CIte Score Rank
Civil and Structural Engineering 232/326 (Q3)
Computer Science Applications 536/747 (Q3)
General Materials Science 329/455 (Q3)
Modeling and Simulation 228/303 (Q4)
Software 326/398 (Q4)
Scopus
SNIP
0,613

2020  
Scimago
H-index
11
Scimago
Journal Rank
0,257
Scimago
Quartile Score
Civil and Structural Engineering Q3
Computer Science Applications Q3
Materials Science (miscellaneous) Q3
Modeling and Simulation Q3
Software Q3
Scopus
Cite Score
340/243=1,4
Scopus
Cite Score Rank
Civil and Structural Engineering 219/318 (Q3)
Computer Science Applications 487/693 (Q3)
General Materials Science 316/455 (Q3)
Modeling and Simulation 217/290 (Q4)
Software 307/389 (Q4)
Scopus
SNIP
1,09
Scopus
Cites
321
Scopus
Documents
67
Days from submission to acceptance 136
Days from acceptance to publication 239
Acceptance
Rate
48%

 

2019  
Scimago
H-index
10
Scimago
Journal Rank
0,262
Scimago
Quartile Score
Civil and Structural Engineering Q3
Computer Science Applications Q3
Materials Science (miscellaneous) Q3
Modeling and Simulation Q3
Software Q3
Scopus
Cite Score
269/220=1,2
Scopus
Cite Score Rank
Civil and Structural Engineering 206/310 (Q3)
Computer Science Applications 445/636 (Q3)
General Materials Science 295/460 (Q3)
Modeling and Simulation 212/274 (Q4)
Software 304/373 (Q4)
Scopus
SNIP
0,933
Scopus
Cites
290
Scopus
Documents
68
Acceptance
Rate
67%

 

Pollack Periodica
Publication Model Hybrid
Submission Fee none
Article Processing Charge 900 EUR/article
Printed Color Illustrations 40 EUR (or 10 000 HUF) + VAT / piece
Regional discounts on country of the funding agency World Bank Lower-middle-income economies: 50%
World Bank Low-income economies: 100%
Further Discounts Editorial Board / Advisory Board members: 50%
Corresponding authors, affiliated to an EISZ member institution subscribing to the journal package of Akadémiai Kiadó: 100%
Subscription fee 2022 Online subsscription: 327 EUR / 411 USD 321
Print + online subscription: 393 EUR / 492 USD
Subscription fee 2023 Online subsscription: 336 EUR / 411 USD
Print + online subscription: 405 EUR / 492 USD
Subscription Information Online subscribers are entitled access to all back issues published by Akadémiai Kiadó for each title for the duration of the subscription, as well as Online First content for the subscribed content.
Purchase per Title Individual articles are sold on the displayed price.

 

Pollack Periodica
Language English
Size A4
Year of
Foundation
2006
Volumes
per Year
1
Issues
per Year
3
Founder Akadémiai Kiadó
Founder's
Address
H-1117 Budapest, Hungary 1516 Budapest, PO Box 245.
Publisher Akadémiai Kiadó
Publisher's
Address
H-1117 Budapest, Hungary 1516 Budapest, PO Box 245.
Responsible
Publisher
Chief Executive Officer, Akadémiai Kiadó
ISSN 1788-1994 (Print)
ISSN 1788-3911 (Online)

Monthly Content Usage

Abstract Views Full Text Views PDF Downloads
Feb 2022 0 0 0
Mar 2022 0 0 0
Apr 2022 0 0 0
May 2022 0 0 0
Jun 2022 0 16 7
Jul 2022 0 51 45
Aug 2022 0 33 22