Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Request For Comment] : about repositories storage strategy #199
I've recently added RSpec unit tests to test the plugin and I discovered caveats in the repositories storage configuration strategy.
I explain :
You have 2 modes to store repositories in Gitolite :
On the top of that you can you decide if repositories identifiers should be unique in Redmine with the
When set to false, then repository identifiers do not have to be unique across projects (although they still cannot have the same value as project identifiers).
This leads to a configuration matrix which looks like that :
The last case is the worst case and should not be used. It leads to buggy behavior like repositories not updated after commiting.
The problem is that you can change any of this parameter at any time and here is the caveat : switching from one case in the matrix to another can lead to the same buggy behavior.
I wrote a complete (I hope) tests suite to test the configuration matrix and switches between each one and could identify several bugs due to the switches.
These bugs cannot be solved as they are not really bugs but more side effects of the configuration matrix and the possibility of switching at any time.
But we can do things to avoid the worst cases to happen :
This means that the button for 'unique_repo_identifier' parameter within Redmine interface will be removed. It will be set with the hierarchical / flat button.
I'd like to have your opinion about this 'issue' and the fix I propose.
Edit (12/06/2014) :
Two examples of side effects :
Hi, thanks for the nice job developing this plugin.
I agree that these 2 options make the most sense.
What we use in some cases is the same repo for 2 projects/subprojects - that woks with the option 1 (hierarchical / unique : false)
I assume this would't work with the (unique : true) setting - or would it?
What is the use case for flat repositories? From my understanding, only with the flat hierarchy are repositories required to be uniquely named. What is the advantage with flat storage?
In an environment with a large number of users, the maintainer of some project X may be unable to assure that a sub-project X/Y is globally unique, whereas in the hierarchical form, only the top-level projects (e.g., X itself) have to be unique.
Why not just stick with hierarchical repositories at all times?
It won't work.
Why not, have to think about it ;)
When you don't want to expose your project hierarchy throught Git (http or ssh) addresses.
That's the purpose of this RFC : take a decision about the storage strategy :)
There is one more possible thing to consider here. Would it be possible to decouple the storage from the access path? What I mean by this is to store the repositories hierarchically, but have a flat access URL. This is actually something I wanted as it would allow you to move the repositories around on the backend without impacting the http/ssh URL.
I'm not sure it can be done fully in the plugin though since the SSH access happens outside the plugin. It was just a wish I had so I could move repositories without having to update the URL everywhere.
Beyond doing something like that, I think there is nothing wrong with only offering the 2 combinations.
referenced this issue
Jun 12, 2014
My thoughts about it:
This would be the best, but as you said, the SSH access happens outside the plugin and Gitolite must have the full repository path to access it.
The reason given above have 2 consequences :
To avoid this... use flat mode ;)