You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Marcus Rueckert <da...@web.de> on 2005/04/10 23:05:06 UTC

[#2270] svn diff behavior

hi,

as mentioned in [1] svn diff sometimes has a bit unexpected behavior.
in this case it breaks the possibility to review changes as patches.

we discussed this issue in #svn and came to the conclusion the current
behavior is by design. but the current design doesnt cover this
functionality.

both, gnu diff and cvs diff, provide "-N" as option for this. eh
suggested "--no-ancestry" as option for diff to get the same behavior.
 
My questions now are:
1. how hard would it be to implement this?
   (You can get the desired output with [2]. chipig created a branch for
    it just to get this change in 2.0.54.)

2. can this be ported to 1.2 if the implementation is done in time?

darix

[1] http://subversion.tigris.org/issues/show_bug.cgi?id=2270
[2] svn diff \
http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x \
http://svn.apache.org/repos/asf/httpd/httpd/branches/mod_version_for_2.0.x

-- 
irssi - the client of the smart and beautiful people

              http://www.irssi.de/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [#2270] svn diff behavior

Posted by kf...@collab.net.
Marcus Rueckert <da...@web.de> writes:
> as mentioned in [1] svn diff sometimes has a bit unexpected behavior.
> in this case it breaks the possibility to review changes as patches.
> 
> we discussed this issue in #svn and came to the conclusion the current
> behavior is by design. but the current design doesnt cover this
> functionality.
> 
> both, gnu diff and cvs diff, provide "-N" as option for this. eh
> suggested "--no-ancestry" as option for diff to get the same behavior.
>  
> My questions now are:
> 1. how hard would it be to implement this?
>    (You can get the desired output with [2]. chipig created a branch for
>     it just to get this change in 2.0.54.)
> 
> 2. can this be ported to 1.2 if the implementation is done in time?

I think it's out of the question for 1.2, at this point (too big).

As for how hard it would be to implement, I don't know.  It first
needs to be established that there's something to fix -- meaning, this
list needs to see the conversation you all had in IRC :-), and the
mail thread needs to be given in the issue, and the issue needs to be
reopened, assuming the conclusions from IRC remain standing.

(Sorry to be such a pedant, but it would be impossible to keep track
of what's going on without such measures.)

Best,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org