commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedikt Ritter (JIRA)" <>
Subject [jira] [Commented] (SANDBOX-462) Refactoring of AccessibleObjectsRegistry
Date Wed, 19 Feb 2014 19:08:19 GMT


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 and create a patch via {{svn diff}}. The patch will
contain all changes in in your working copy compared to the base revision (which is
* Now you make another change to 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


> Refactoring of AccessibleObjectsRegistry
> ----------------------------------------
>                 Key: SANDBOX-462
>                 URL:
>             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

View raw message