> From: Nick Colgan Wednesday, October 28, 2009 7:06 PM
> I'm currently working on a project made up of parts that could each be
> considered a project in itself. I plan on using redmine or trac to
> manage the project. Now I'm trying to figure out how to manage the
> repo(s) for the project.
> These are the current options I have in mind:
> 1. Create a separate repository for each sub-project and manage each
> separately in redmine (separate bug tracker, wiki, etc.)
> 2. Create a single repository with a subdirectory for each
> 3. Use git submodules or subversion externals to combine options 1 and
> by creating a separate repo for each sub-project, then creating a
> repo with subdirectory for each sub-project that imports from their
> respective repositories.
> What's the best way to handle this situation? Are git submodules
> svn externals sufficiently capable of dealing with this?
I'll be most interested in your decision.
We have 4 components that are used in various combinations in 4
Project 1 uses components a & b
2 uses just a
3 uses a & c
4 uses b & d
Right now we have everything in one repository and use sparse checkouts.
have 10000 commits and our repo is about 4.5 GB. We have about 10
users. We use VNC a lot, so most access is using svnservers here, but we
also support svn+ssh. Some of the code we bought and have modified, so
least one component uses the vendor branch model.
Advantage of the single repo -- easy to branch all projects at the same
Disadvantage -- I have to have one workspace for each branch that has
EVERYTHING checked out so I can do merging.
I suppose you could argue that another disadvantage is I cannot do
control by project.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-29 14:39:22 CET