--- Eric Gillespie <epg@pretzelnet.org> wrote:
> I have seen this stated a few other places, but i don't understand
> it. I am currently managing multiple projects in one repository,
> the same way i did in CVS. It works quite well, and i'm sure there
> are advantages i haven't thought of to having them share the same
> database back-end (i imagine this will become even more valuable
> when a SQL back-end becomes available).
>
> I don't want to deal with separate repositories, and i probably
> won't be the only one. What makes you think this behavior opposite
> to that of CVS users will become common?
I am not up to speed on subversion triggers or access contol mechanisms yet,
but I am current managing about 25+ (growing to 50-60 by year end) CVS non-root
pserver repositories on one server. I do this to easily control access to
individual projects, control branch access on individual projects, prevent user
manipulation of CM tags and prevent user UNIX level access to the physical
repository on the server. I can setup the same triggers scripts for all
repositories that read repository specific info/config files to use on policy
enforcement for that project.
I have not had a chance to look into subversion's ablilty to be used as a CM
tool (as opposed to just a version tool used by the open source community) and
its ability to provide triggerable actions for scripts to do CM stuff, but I
would hope it at least allows the CM process level I have on CVS. I am not sure
how atomic commits and related log info from one project will fair as part of
every other projects repository and history. I am looking at the atomic commits
as a comparible feature to ClearCases UCM. A commit being a change set. Not
perfect, but if you try UCM and know its implemetation of change sets,
subversion might not be that far off from perfect when it comes to change sets.
I am sure I am not making much sense (its late, if I'm losing you please read
on I think I have a good point or two below), but when I take over projects
that have had a developer managed CVS repository, I usually break out projects
into their own CVS repos under CM.
It might be that the developer managed repos tend to collect all projects and
the CM managed repos separate them, I guess its how you plan to use the tool
and which method best meets your needs or is the path of least resistance.
However, I see projects come and go. It would be good to be able to cut the
project that is inactive/obsoleted/replaced/canceled or whatever onto CD and
remove it from the server. Or if the project gets transfered to another group
in the company, to be able to transfer the repository would be essential. So
there are reasons for having separate repos for separate projects.
As for the SQL backend, it would be good if the same instance of the DB could
be used for all repos on the server, either on or many, if it can be setup to
do so.
> I don't think cross-repository modules will be as important as you
> think, but if i am wrong there is still a better way to handle it
> than text files.
It might be nice to have a tools repository that is setup to be checked out
with individual project repositories (different projects may be at different
versions of tools, so would have to be linked by tag). Currently this lacking
feature causes projects to store needed tools inside their individual repos.
Mark
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 2 04:42:14 2002