[ 
https://issues.apache.org/jira/browse/SANDBOX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905893#comment-13905893
 ] 

Benedikt Ritter commented on SANDBOX-462:
-----------------------------------------

Hello André,

SVN can only create a patch against the BASE revision of or working copy (that 
is the revision that was HEAD in the repo, when you called svn up the last 
time).  So if you add change after change, they will all end up in the patch. 
To make this clearer:

* You update to HEAD, let's say that's revision 19.
* You make a change to file A.java and create a patch via {{svn diff A.java}}. 
The patch will contain all changes in A.java in your working copy compared to 
the base revision (which is 19).
* Now you make another change to A.java that is unrelated to the first change 
and create a new patch. The patch will again be created against the base 
revision. So it has to create all the changes you made before.

Just ask yourself: how could svn know about which changes have to be combined 
for a patch. The fact that your changes had a temporal ordering is not 
available to SVN. It's just something that you and may be the editing history 
of your IDE knows.

So you either have to: 
a) make your changes, create the patch and revert to your base revision, or
b) make your changes, create the patch, then wait until the patch has been 
applied, update to head and then create the next patch

HTH,
Benedikt

> Refactoring of AccessibleObjectsRegistry
> ----------------------------------------
>
>                 Key: SANDBOX-462
>                 URL: https://issues.apache.org/jira/browse/SANDBOX-462
>             Project: Commons Sandbox
>          Issue Type: Improvement
>          Components: BeanUtils2
>            Reporter: Andre Diermann
>            Priority: Minor
>         Attachments: Commons-BeanUtils2-462.patch
>
>
> Summary:
> The AccessibleObjectsRegistry class provides two get methods, while one is a 
> convenient method for the other.
> Both methods take one conditional parameter, boolean exact, and the actual 
> get method is very long, which makes it somehow complex to understand.
> Suggestion:
> What could be improved IMHO:
> - Instead of using conditional methods, like get(boolean 
> doSomethingSpecialIfTrue, ...), it is more convenient to provide dedicated 
> methods like getSomething() and getAnotherThing().
> - In this regard the difference between an exact or, let's call it, matching 
> descriptor should be expressed through inheritance rather than object 
> allocation (= expressing it by a field boolean exact).
> - The very long get method should be refined
> - Another very minor issue is the naming of the paramTypes field within the 
> inner AccessibleObjectDescriptor class, which I would suggest to rename to 
> parameterTypes to fit the naming of the other occurrences. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to