On Thu, 2013-04-18 at 07:18 -0700, BRM wrote: > So what if you have changes to the local working copy? > Or are you ensuring you have no other changes first?
Right, I'd ensure the files being modified in the patch have no changes in my WC first. > > As Branko Čibej noted, the only clean way to do it is to use a new (or > a dedicated) working copy. > > Sadly, there is nothing like TSVN for Linux. If I get around to creating a script to help w/ this workflow, I'll share it. > > Ben > > > > > ______________________________________________________________ > From: Nick <nos...@codesniffer.com> > To: BRM <bm_witn...@yahoo.com> > Cc: users <users@subversion.apache.org>; > "d...@subversion.apache.org" <d...@subversion.apache.org> > Sent: Wednesday, April 17, 2013 4:12 PM > Subject: Re: Changelist support for svn patch? > > > > On Wed, 2013-04-17 at 11:42 -0700, BRM wrote: > > I'd suggest a slight modification to your process if you can > - that > > is: > > > > 1. Checkout a new working copy > > 2. Apply the patch to the new working copy > > 3. Review > > 4. Delete the new working copy > > > > Now I realize in some cases that may not be an option - too > large a > > down, etc. > Right, checking out a new WC for each code review is not > feasible for > me, and sort of seems like overkill. I figure the worst case > scenario > is to generate a script which parses the patch and downloads a > local > copy of each file referenced in the patch (at the specified > rev) into a > temporary tree (sort of a sparse checkout), apply the patch to > the tree, > and then can launch a diff tool against it. > > > If the patch provider is using SVN, which I assume they are > since > > you're talking about apply a patch with SVN, then if it is > all > > committed you could also use TSVN's Repository Viewer to > look at the > > patch by comparing two branches, and then using TSVN's Diff > > functionality to look at each modification, just like you > are in your > > working copy - only you don't need a working copy to do it. > > I'm using Linux, otherwise I'd just use TortoiseSVN which > seems to be > able to do what I describe above. > > > > > Any how...something to think about for you. > > > > Ben > > > > P.S. Aren't "Changelists" client-side only? > > Yes, they are client-side only. > > > > > > > ______________________________________________________________ > > From: Nick <nos...@codesniffer.com> > > To: Philip Martin <philip.mar...@wandisco.com> > > Cc: users <users@subversion.apache.org>; > > d...@subversion.apache.org > > Sent: Wednesday, April 17, 2013 10:23 AM > > Subject: Re: Changelist support for svn patch? > > > > > > On Wed, 2013-04-17 at 11:43 +0100, Philip Martin > wrote: > > > > The 'patch' subcommand does not seem to support > applying a > > > changelist > > > > description to the files that are part of the > patch. Any > > plans to > > > > support this? > > > > > > > > (Should I be asking this on the dev list?) > > > > > > That sounds like a useful feauture. > > > > Here's the workflow which provoked my asking. I > wonder if > > there's an > > alternative (and maybe more streamlined) method of > > accomplishing the > > same. > > > > I received a patch containing a feature addition for > a project > > I'm > > working on. My primary interest is only to view the > changes > > (ie. code > > review)--not to submit them. AFAICT, the way to do > this using > > subversion directly (ie. not a wrapper app like > TortoiseSVN) > > is to apply > > the patch to my working copy and then view the diff. > (I'm > > ignoring the > > option of viewing the raw patch file directly in an > editor.) > > Once I'm > > done reviewing, I want to remove the change. Without > the > > ability to > > apply the patch into a specific changelist, I have to > > surgically revert > > the changes if I have other changes of my own in the > WC. If > > the patch > > were applied to a changelist, I can revert it all in > one shot. > > > > Am I missing something for this workflow? Is there a > simpler > > way? How > > do others handle this scenario? > > > > > > Nick > > > > > > > > > > > > > >
