El dom., 6 ene. 2019 a las 13:49, Mads Kiilerich (<[email protected]>) escribió: > > Hi > > Kallithea has some inherited "locking" functionality. Something where a > "pull" from the repository will lock it, so nobody else can push until > the user that pulled has pushed again. > > There are good use cases for file locking - especially if tracking > unmergeable files like binary assets. But the current Kallithea doesn't > seem like a good way to do it: > > Locking of the whole repository is too coarse, and triggering it as a > side effect of pull/push makes the work flows fragile and inflexible. > > More important for me right now: The implementation is hard to maintain > and also makes it harder to maintain other parts. It is quite invasive > and fragile and seems buggy ... and is hard to clean up and fix. > > I would thus prefer to drop the existing locking functionality. I think > Kallithea would be better without it. If we want something in this > direction, I think it would be easier to start from scratch than to > maintain and evolve what we have now. Any needs for "locking" is > probably currently better solved by adjusting access control or making > custom hooks. > > Are there any happy users of the current locking functionality that > would miss it? Can you say more about the use case and how will it works? >
We are also not using it. /Thomas _______________________________________________ kallithea-general mailing list [email protected] https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
