Stash 2.4, released in early may, brings some really cool new features. From an enterprise point of view, the release notes can be summarized this way:
- Stash now supports forking
- It’s possible to set permissions for individual repositories (previously only project-based permissions were possible)
- Personal repositories (comparable to personal spaces in Confluence)
A nice overview of these features is available on the Stash website.
From my personal point of view, these features fill some serious gaps that I missed while working with Stash in the last couple of months.
In the past, there were cases that made you set up multiple projects in Stash to solve aspects related to external coworkers. While Stash 2.0 featured write-permissions on a branch level, read-permissions could only be restricted by using multiple projects.
But besides this, large companies will benefit in other ways from these improvements…
For example think about this scenario: A common library that’s shared by multiple project teams. Every project team contributes new code, but that could break other projects or simply introduce bugs in a phase of heavy development. That’s why it is often preferable to have a dedicated branch or even a clone of the repository for each project using it. Then it is possible to contribute back to the original branch/repository when the project is in a stabilized state. Using forking support in Stash 2.4, this workflow can be managed much easier and cleaner as before.