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 <nospam_at_codesniffer.com>
> To: BRM <bm_witness_at_yahoo.com>
> Cc: users <users_at_subversion.apache.org>;
> "dev_at_subversion.apache.org" <dev_at_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 <nospam_at_codesniffer.com>
> > To: Philip Martin <philip.martin_at_wandisco.com>
> > Cc: users <users_at_subversion.apache.org>;
> > dev_at_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
> >
> >
> >
> >
> >
>
>
>
>
Received on 2013-04-19 16:08:52 CEST