Re: Resources to help design a subversion repository

Carl,

I recommend you install trac, and keep all the change requests in there. We've been using 2 approaches, for a site that has a bunch of small fixes/additions, both dev and production are checked out working copies of the trunk. For small changes, changes are done directly on trunk and pushed to prd. For larger changes, we create a tag and a branch based on the ticket number and after its done, its merged into the trunk and pushed to prd.

For another project, we are working on a large revamp, so dev points to trunk, while production points to a branch. Bigfixes are done on the branch and pushed out to production. They are also merged into the trunk.

When we're done with the large redevelopment, we plan to point prd to trunk again.

Hope this helps,

Russ
Sent wirelessly via BlackBerry from T-Mobile.

-----Original Message-----
From: "Carl Lerche" <clerche@tarot.com>
Date: Wed, 24 Jan 2007 15:28:38
To:<users@subversion.tigris.org>
Subject: Resources to help design a subversion repository

Hello all,

I've been a casual user of subversion for a while (just doing basic
developer functions, check out, check in, branching, etc...). I'm going to
be in charge of designing from the ground up a new repository layout for the
massive amount of source code my coworkers and I deal with.

I was wondering if anybody could point me to any good resources, books, or
anything that could help me as I read up as much as possible about designing
an SVN repository as well as just good source code management procedure
(this is for a web application, so anything that might cover how to manage
the source code for a massive web application would help. For example,
branching the trunk for various projects then merging / integrating it back
to the trunk, deployment from subversion, etc...).

Just off the top of my head, the way I would set it up would be have the
trunk and make each person / group working on a project to branch from the
trunk to develop the project and then merge back into trunk when they are
done. Like this, the release # that the branch was merged to is the one that
is deployed. Hopefully this makes sense.

Anyway, I would like to research more into this, so any resources are
welcome.

Thanks,
-carl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 25 02:00:08 2007