On Tue, Aug 5, 2008 at 11:19 AM, Jesse Vincent <[EMAIL PROTECTED]> wrote: > > On Aug 5, 2008, at 10:51 AM, Will Coleda wrote: > >> Using svn as a backing store, how can we more easily work with long >> lived branches? >> >> I've some existing branches which are long lived, and doing the svn >> merge either way is extremely slow. >> >> I know much of our community used svk for a while; I think the usage >> there has dropped off as git is the new shiny. My usage of svk was for >> local branching; I couldn't easily share my work in progress with the >> community. >> > > Not that I'm biased, but.... > > SVK 2.2b1 is out today. It contains many, many bugfixes and performance > improvements (http://search.cpan.org/~clkao/SVK-v2.1.99_01/) > > It also has a bunch of new features. The one that's made my life easier is > the new "branch" command. > > "branch" is designed to encapsulate the sorts of branching operations people > working on a project often actually _do_. In addition to the below, there > are more tools to help release engineers keep track of and merge branches. > > # create a branch > svk br --create p5-implementation parrot > > # get a checkout > > svk br --co p5-implementation parrot > > cd p5-implementation > > # hack hack hack > > # realize you're late for your plane > > svk br --offline > > # svk clones the remote branch to local > > # hack hack hack > > # land, find net > > svk br --online > > # svk merges down changes from the upstream copy of the branch and then > pushes your changes > > > If this seems appealing, I'm sure I could get some clkao cycles if there's > more you folks need. > > -j > > >> Does anyone have *any* recommendations? (including: you're doing the >> merge wrong). >> >> I'm bccing the current svn admins to find out if they have any ideas as >> well. >> >> Would an upgrade on the server side to 1.5 help with performance? (It >> would certainly make the maintenance aspect of the merging less >> painful.) >> >> -- >> Will "Coke" Coleda >> > >
Sounds spiffy. So these branch commands actually create branches on the svn repository that's doing the hosting, so they're defacto shared with the community in the obvious location? (presuming you're online and pushing changes back?) That seems to be the best of both worlds, presuming it handles the merging better/faster/cleaner than 'svn merge' does. -- Will "Coke" Coleda
