On Tue, Nov 26, 2013 at 8:02 PM, Edward Ned Harvey (svn4) <s...@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 lesmikes...@gmail.com