[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Fix --depth behavior for svn add (Re: Semantics of --depth: should define WC-depth for omitted-items?)

From: Rui, Guo <timmyguo_at_mail.ustc.edu.cn>
Date: Sat, 26 Apr 2008 01:35:48 +0800

On Fri, Apr 25, 2008 at 07:50:09PM +0300, Daniel Shahaf wrote:
> Rui, Guo wrote on Sat, 26 Apr 2008 at 00:19 +0800:
> > PS: I'm really not good at splitting a unified patch into logical independent
> > changes sets. What's the best way of handling this? I just edit the patch file
> > by hand this time and not sure about whether they are still valid.
> >
> You could use the (new in 1.5) changelists feature, and do 'svn diff
> --cl CLNAME' to get the diff for changelist CLNAME.
> Is there an easy way, however, to get 'svn diff' to output files' diffs
> a particular order?
What if a file falls into both of the logical independent change sets? Just as
the situation here. I think this is where the headache comes from.
> > Here are change logs for the patch:
> > [[[
> > Make the --depth option in svn add works in the same way with svn ci, up etc.
> > ]]]
> >
> > And I also made some cleanups for the code:
> > [[[
> > Some cleanups:
> > ]]]
> >
> (patch manager hat on)
> Rui, it would be easier to review your patches if you said which log
> message goes with which patch (although, this time, I could guess it from
> the filenames). You might also include the log message at the top of the
> patch file (patch(1) would ignore it).
Shy, my fault. I should be more considerate. Thanks for reminding.

PS: I have to admit that I never manipulated patches directly,
thanks to svn. :-)

Rui, Guo

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-25 19:36:09 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.