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.
-
Personally I prefer each project in it's own repository
From paan -
As long as each project has /trunk /tags and /branches you're good. Proper continuous integration is the criterion here.
From Matt Hinze -
Yes, put everything in source control.
If you're using SVN, keep projects in their own repository - svn is slow, and gets slower.
Nicholas Riley : While Subversion might be a bit slow, I've certainly not noticed it slow down with the kinds of load a personal project would be remotely likely to inflict; the added administrative overhead of multiple repositories would be much more annoying.From Marcin -
I would absolutely keep each project in its own repository, separate from all others. This will give each project its own history of commits. Rollbacks on one project will not affect other projects.
Dima : If you keep your projects in separate directories in a single repository, then each project would still have its own history of commits.Derek Park : Rolling back a change can be done at pretty much any granularity level. There's generally no reason for it to be done at the repository level. Changelogs can likewise be accessed at a directory level. You will be dealing with directories (branches) even if you have one project per repository.From Steve Paulo -
My rule of thumb is to consolidate things that are delivered together. In other words, if you might deliver project X and project Y separately, then put them in separate repos.
Yes, sometimes this means you have a huge repo for a project that contains a huge number of components, but people can operate on sub-trees of a repo and this forces them to think of the "whole project" when they commit changes to the repo.
From andy -
If your projects are independent, it's fine to keep them in separate repositories. If they share components, then put them together.
From Dima -
For Subversion, I'd suggest putting everything in the same repository; the administrative overhead of setting up a new repository is too high to make it a no-brainer, so you're more likely not to version something and regret it later. Subversion provides plenty of fine-grained access controls if you need to restrict access to a portion of your repository.
As I begin to migrate my projects to Mercurial, however, I've switched to creating a repository per project, because it just takes a "hg init" to create a new one in place, and I can use the hg forest extension to easily perform operations on nested repositories. Subversion has svn:externals, which are somewhat similar, but require more administrative overhead.
Oddmund : Setting up SVN is not hard.Steve Jessop : I was going to say that, but then it occurred to me that maybe not everybody uses just local repositories for their own stuff. If you plan to set up a web interface, and access restrictions, and so on, for each repository, then it's more than no work. Although I imagine it's scriptable.Nicholas Riley : Yeah, that's what I meant - repositories that aren't network accessible aren't terribly useful to me as I work from at least 5 machines every day. (I realize I'm probably in the minority that way).From Nicholas Riley -
If you're going with a separate repository for each project, you might use the External tag to refer to other repositories -thus share code.
From Silver Dragon -
I would store them in the same repository. It's kind of neater. Plus why would it matter for continuous integration and such - you can always pull a specific folder from the repository.
It's also easier to administer - accounts to one repository, access logs of one repository etc.
From Svet -
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.
From Steve Jessop -
If you work with a lot of other people you might consider whether everyone needs the same level of access to every project. I think it is easier to give access rights per person if you put each project in a separate repository. ~~~
From Steve Pitchers
0 comments:
Post a Comment