I am currently using TortoiseSVN to manage a couple of the projects that I have on the go at the moment. When I first moved everything into source control I wasn't really sure how everything should be laid out so I ended up putting each project into its own repository.
I was wondering would it be a good idea for me just to move them all into one big repository and have them split into project folders? What does everyone else do?
At the moment none of them share common code but they may in the future. Would it make it easier to manage if they where all together.
Thanks.
Solution 1A single repository can contain multiple independent branches, called orphan branches. Orphan branches are completely separate from each other; they do not share histories. This creates a new branch, unrelated to your current branch. Each project should be in its own orphaned branch.
With Git, using multiple repositories is the only way to work efficiently. This enables each team to work independently, and do their work faster. You can also make sure that developers only have access to the repositories they need access to (thus making Git more secure.)
If the project you are on is a single project with lots of parts it is less important to keep things separate. It might still be easier if each module were separate. But if you have lots of small or medium projects that use various modules then it is very useful to have separate repos.
keep the methodology as it currently is, with one repo per solution.
Depends to an extent what you mean by "project".
I have a general local repository containing random bits of stuff that I write (including my website, since it's small). A single-user local SVN repository is not going to suffer noticeable performance issues until you've spent a lot of years typing. By which time SVN will be faster anyway. So I've yet to regret having thrown everything in one repository, even though some of the stuff in there is completely unrelated other than that I wrote it all.
If a "project" means "an assignment from class", or "the scripts I use to drive my TiVo", or "my progress in learning a new language", then creating a repos per project seems a bit unnecessary to me. Then again, it doesn't cost anything either. So I guess I'd say don't change what you're doing. Unless you really want the experience of re-organising repositories, in which case do change what you're doing :-)
However, if by "project" you mean a 'real' software project, with public access to the repository, then I think separate repos per project is what makes sense: partly because it divides things cleanly and each project scales independently, but also because it's what people will expect to see.
Sharing code between separate repositories is less of an issue than you might think, since svn has the rather lovely "svn:externals" feature. This lets you point a directory of your repository at a directory in another repository, and check that stuff out automatically along with your stuff. See, as always, the SVN book for details.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With