> 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
sub-project.
>
> 3. Use git submodules or subversion externals to combine options 1 and
2
> by creating a separate repo for each sub-project, then creating a
master
> 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
and/or
> svn externals sufficiently capable of dealing with this?
>
> Thanks,
> nic.
I'll be most interested in your decision.
We have 4 components that are used in various combinations in 4
projects.
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.
We
have 10000 commits and our repo is about 4.5 GB. We have about 10
regular
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
at
least one component uses the vendor branch model.
Advantage of the single repo -- easy to branch all projects at the same
time.
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
access
control by project.
JLM
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2412623
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-29 14:39:22 CET