Hey Roey, it's good to hear that you found a way to make SCC work for you!
1. What is the correct method to maintenance the Reusable folders?
I fear there's no single correct method for that...
I understand that every submodule is like a reference to a specific commit in the folder.
When you integrate another repository into your project repository by means of git submodule, git by default links it to a specific commit, just like you say.
Recent versions of git support tracking a specific branch within a git submodule. We at HSE did not really benefit from this (or don't understand it well enough), so we don't make use of this feature (see below).
So when I make changes in the submodule does it correct to push it to the bare repository? In addition, Is it necessary to maintain the reusable fioder by itself? (If for example I will clone the bare repository into itself I will have all the files there. Do i need it?
This depends on your way of working. At HSE, we usually only use git submodules when we want to modify the code inside the submodule from within the containing repository's application. You can find more about HSE's git submodule usage in our Dokuwiki.
For reusable code that can be developed and modified on its own (and which we don't want to modify from within a customer project), we would not integrate it as a submodule but rather create a package (*) and then use the released package in our projects.
(*) For us a HSE, a package can be
- a source distribution which we copy into our project (usually for the more involved, HSE-specific reuse libraries)
- a VI package which we install into vi.lib (usually for the more generic reuse libraries)
In a nutshell, we want as many dependencies as possible in our project repositories (i.e. not installed somewhere else like vi.lib). More about this again in our Dokuwiki.
2. I read a lot about VIPM, but I cannot understand how it helps me and if it an alternative to submodules or maybe I can combine between them (as Fabiola suggested in one example which I don't really understand..). specifically - if I create a package of my folder then the vi's are stored in vi.lib or user.lib, so all the changes will not be in the files that is in the repository. How do I SCC the files that way? and why do I need it?
Using VIPM and VI packages gives you a number of advantages:
- building a package equals creating a proper, named release of your reuse library
- you can easily distribute your reuse library, others can easily install it
- source code installed via VIPM into vi.lib is usually not modified when working on a project - the fact that the reuse library is stored into vi.lib is a strong sign that it should not contain project-specific code (unless you consciously use it that way).
One way to do this would be to have the bare repo for your reuse lib on your network share and work on it by cloning the bare repo to your working directory (as you already do). Once you're happy with the state of your reuse library, you could then "create a release" (**) by building a VI package.
In your projects, you would not include the reuse library via a git submodule, but you'd instead use it from vi.lib - i.e. using the VIs which you installed via your VI package and which now live in vi.lib.
If you need to add features to your reuse library or fix a bug, you would go back to the working directory of your reuse lib's repo, make your changes, build a new VI package, install it via VIPM into vi.lib, and THEN go back to your project and use those new (or updated) VIs.
(**) There are many more ways to do this than only VIPM. You could mark specific commits in your reuse library as releases, eg by adding a git tag. That way, when you integrate the reuse lib into your project via git submodules, it is easier to find which exact commits you would like to actually track.
Again, there is an abundance of possibilities to do all this. We have found a good way for us, and we even automated part of it (<- shameless advertising).
