Subject: Re: Re: Best practices? (a little off topic)
Newsgroups: gmane.comp.lang.ruby.rails
Date: 2005-09-29 22:52:17 GMT (3 years, 39 weeks, 4 days, 23 hours and 43 minutes ago)
On Sep 29, 2005, at 2:40 PM, Michael Schuerig wrote: > On Thursday 29 September 2005 22:22, François Beausoleil wrote: >> Michael Schuerig said the following on 2005-09-29 15:57: >>> I've got the same response, on the subversion mailing list no less, >>> when I asked about the same problem. I have applied more patches to >>> my local rails installation than I'd like to and I have found no >>> way to keep the changes under version control. -- But I really >>> don't want to learn yet another VCS, I've only recently switched >>> from CVS to subversion. >> >> I don't personally use SVK, but the changes might not be that big - >> SVK uses Subversion under the hood, so knowledge about SVN should >> port pretty easily. >> >> Else, you'll need to do vendor branch management yourself, with all >> the headaches. > > I'm tracking the edge and am doing an svn up at least once a day. > Otherwise my most important patch[*] would be obsolete in no time. > Doing a vendor branch each time looks prohibitive. Also, I'm not > yet so > very comfortable with subversion that I can handle all this easily. I can't recommend svk enough for exactly this scenario. For any work beyond simple fixes, I make a local branch of the remote svn trunk (cool!) and do the coding and testing locally. When the trunk changes but I'm not done with my feature, I can merge the changes since my last merge with a single command. When I'm done and everything tests out, I can push back to the remote svn trunk with a single command, either as a real commit or as a patch! Quickstart: # Mirror the remote svn repos to my local svk depot. You'll see paths # beginning with // in svk a lot -- they are paths within the local depot. svk mkdir //rails svk mirror http://dev.rubyonrails.org/svn/rails //rails/mirror # Check out the mirror and play with it if you like. Working on this # checkout with the svk commands is like working with a proxy for the # real repository: 'svk commit' sends the commit back to the mirror, etc. svk co //rails/mirror/trunk cd trunk/activerecord vi CHANGELOG svk commit -m "..." CHANGELOG # Make a local branch of the mirrored trunk to develop a feature. # Note that my use of //rails/mirror/trunk as the path for the mirrored # svn repository and //rails/tickets/ticket-num for ticket-fix branches # is arbitrary -- this is a convention similar to the way svn encourages # tags, branches, trunk, etc. svk mkdir //rails/tickets svk cp -m "Branching for ticket #2172" //rails/mirror/trunk //rails/ tickets/2172 vi foo svk commit foo svk move foo bar svk rm baz etc. # I'm not done yet but decide to call it a night. In the morning a bunch # of new changesets have gone into svn trunk. Merge them with this branch. svk pull # Do more edits and commits. Write the tests. The feature is done. # # Pull changes from trunk again so the patch is current. (NOTE that svk # knows when we've merged branches, so only changes since the last merge # are pulled! This is *the* most aggravating thing about branch # management in svn.) svk pull # Now we're ready to create the patch. This creates # ~/.svk/patch/ticket-2172.1.patch svk push -P ticket-2172.1 # Or write the patch to stdout. svk push -P - > ~/ticket-2172.patch # Still waiting for patch to be applied, but trunk has been updated. # Plus we want to improve the feature. svk pull ... edit ... svk commit svk push -P ticket-2172.2 # Finally the patch is applied. But a bug turns up we need to fix. svk pull ... edit .. svk commit svk push -P ticket-2172.3 # The patch has been applied for a while with no further issues. # Archive the branch. svk mkdir //rails/tickets/closed svk mv //rails/tickets/2172 //rails/tickets/closed/ # Or just remove it. svk rm //rails/tickets/2172 The online manual is adapted from the svn book: http://svkbook.elixus.org/nightly/en/svk-book.html An recent interview with its creator: http://www.oreillynet.com/pub/a/network/2005/09/20/painless- merging-with-svk.html I didn't mean this thread to become an svk advertisement, but there you have itBest, jeremy