I'm at almost the same point, perhaps a little ahead of you, evaluating
Subversion for a new product. (Moving from PVCS and VSS, currently no need
to preserve any existing code in SVN.)
> -----Original Message-----
> From: Rob Wilkerson [mailto:r.d.wilkerson@gmail.com]
> Sent: Friday, June 23, 2006 12:27 PM
> To: users@subversion.tigris.org
> Subject: SOT: Best Practices Guidance
>
> [...]
>
> 1. Set up a single product repository with separate projects for the
> core, each module and documentation
The product we're working on is built on an SOA model, with different
components potentially releasing upgrades at different times. So we're
planning a repository per component, with potential multiple projects per
component, depending on how things decompose.
> 2. Within each project trunk, branches and tags folders will be
> created/imported
We're undecided whether to have project/trunk or trunk/projects. I've found
both discussed as I poke around the documentation and the web. I'm leaning
toward trunk/project, which makes it very easy to get the entire component
at one time from the trunk. Using project/trunk, you've got to visit each
project separately to check it out, and tagging and branching work
multiplies.
> 3. Initially, the trunk of each project will contain the code as it
> was released in the prior version
> 4. Branches will be created for each segregated development effort
>
> QUESTION : do all developers typically check out an *entire* code base
> from the trunk or only those projects/files that pertain to their
> development effort? In VSS-land, of course, we only checked out what
> we were actively working on and "got latest" of everything else.
Remember that "checkout" doesn't have the same meaning in Subversion as
you're accustomed to. It doesn't normally cause a lock on anything, so
there's no risk to other developer's productivity in getting the entire
trunk. A SVN "checkout" really means "get the latest version".
I'm anticipating that my team will get everything they need to work on their
assignments. Depending on assignments, that may mean the entire product
with all libraries and components, or it may mean only a component, or
possibly even just a project within a component.
>
> 5. When dev/unit testing is complete, merge and commit any changes.
>
> QUESTION : does this remove the branch folder from the repository?
Not unless you delete it. We're thinking at the moment of planning for
branches by developer (branches/developer/project), and let the developer
determine when they really want to branch vs. work against the trunk.
> 6. To create a release, tag the entire trunk. To create a service
> pack/hotfix, tag only those files/folders that need to be packaged and
> export the tag contents to the build server to execute the build
> process (using Ant).
I haven't thought about service pack/hotfixes, since that's typically not
something we will do. But as far as "tag the trunk to create a release",
that's the way I understand it.
I'm looking forward to learning from other people's responses, too.
--
Dennis R. Sherman
Endeavor Information Systems
847-227-2976
Dennis.Sherman@endinfosys.com
http://www.endinfosys.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 23 20:24:45 2006