On Tue, Nov 26, 2013 at 8:02 PM, Edward Ned Harvey (svn4)
<svn4_at_nedharvey.com> wrote:
>
>
> At first, I was doing a sparse checkout. I non-recursively checked out /, and then I made /trunk fully recursive, and then I went one level deeper into /branches, and then I made /branches/eharvey fully recursive... And then I discovered how natural it was to switch & merge, so I got rid of my whole working copy, and re-checked out recursively (non-sparse) /trunk. But it sounds like you suggest going back to the non-recursive checkout of /, with recursive /trunk, and recursive /branches/eharvey.
Not sure what you mean about with sparse and recursive checkouts or
why you'd start with /. If there is one project in the repository
you would normally just check out /trunk. Or with multiple projects,
/project_name/trunk.
> Just to keep the branch & trunk logically separate from each other and eliminate any user error regarding "Which what, oh, where am I? I forget..." You might be right... and if I say so to the other guys, they might use this to bludgeon me into git. ;-)
You can have multiple checkouts that don't really affect each other,
so yes sometimes it is simpler to just have a parallel checkout of a
branch unless there are bandwidth or disk space constraints that make
switching more efficient.
If your project is large enough to split out libraries that can be
developed separately, consider moving them out to project-level
directories or separate repositories, and assembling the components
you want in the main project with svn externals. Then each component
can have its own release scheduling (make tags, then when a project
using the component wants to update, change the external to the newer
tag). This lets your team work on different parts without too much
impact on each other while still being able to build the whole thing
easily.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-11-28 06:38:50 CET