Were I work we have a monolithic subversion repo that contains : - DBs ddl - Selenium automatic tests - A hierarchy with our Java code were we have our libra

Were I work we have a monolithic subversion repo that contains : - DBs ddl - Selenium automatic tests - A hierarchy with our Java code were we have our libraries, modules, final products and client personalization of our products. Our build solution relay on Maven with a nexus server and Jenkins to autodeploy maven artifacts. Pros : - We can do a single commit across all to update many modules/libs/final product to fix a issue or implement something new. So tracking a issue fix or a new feature across all is more easy. Contras : - We can't work like in git, where we can create a branch to develop a new feature or fix a issue isolated from other changes. - Enforces big commits. Actually I managed to use git svn to map our subversion repository, but I need to create many small git local repositories to track every module/lib/product/personalization that work over. Also, I have a few scripts to update my git local repos (master branch) against the subversion repo. This allowed me to be more flexible when I work on a new feature or a potential dangerous change, as I can create local branches, do local commits (and do a commit squash of they before send to subversion), stash , etc. I think that with this I grab the best of both ways of working. I can be more flexible and more productive, as I can change of branch of a project/module/lib with a few keystrokes, and do local code versioning. At same time. I only miss doing a commit across modules/libs/products when to resolve a issue I need to do change across many modules/libs. On this case, I try to use the same commit message or at least, put the issue number on the commit message, so make easy track it on fisheye.