I've submitted for review a change set. Unfortunately i forgot to refresh my sandbox first, so that means I did not include some changes in that set.
So i lost the option to add changes to my change set.
I don't want to discard that change set because it contains important changes. I also don't want to have to deliver 2 change sets, because they contain atomic logic (logic that can't be split).
I'm having a feeling that the "reverse" option would get my change set back into an editable state, but i really have no idea what to do here.
To sum up: i need to make my change set editable again, so that i can merge it with another one.
Anyone know how i would do this?
Thx, you guys rule!
I don't think you can revert back to a mutable state for your change set, if that change set was "completed" before being submitted for review.
In that case, a "reverse" (ie doing a new changeset cancelling the previous changeset), followed by a new changeset in which you redo your work and re-submit it for review might be the only solution.
However, following this example of code review in RTC, change sets should be ket mutable during the review (for the original programer to check-in new revisions of his files based on the feedback of the reviewers).
You should create the new change set.
I say this for two reasons:
1) The aesthetic argument for only having one change set per work item quickly breaks down in practice - it's easy to forget a change, and you may have to make amendments due to bugs or review comments.
2) Having multiple change sets makes your changes easier to understand. Each change set can contain a logical set of changes, so a single work item may have three change sets: "Refactor code", "Update copyrights", and "Changes from review". That way, when someone annotates the files in future, they'll get something at a finer granularity than the initial work item.
Regarding the "atomic logic" argument: it probably isn't an issue unless your team is in the habit of delivering/discarding individual change sets. On the RTC project, we regularly split logically discrete changes across multiple change sets and multiple components.
If you're concerned that you may deliver change sets that logically depend on changes in other components (as I occasionally do), I suggest you chime in on bug 150421. Bug 153907 describes a similar problem, but requires a much more complex solution (making it less likely to be implemented without customer pressure).
I runned into the same issue, and decided to create a patch, discard my changes and then create a new changeset.
Related
Is there a way to undo last function/method which is just finished to work?
for example I have a function/method which is doing this:
isTrue = false
num+=5
and many more functions. Each function start to work when user presses certain button on a screen. User should have possibility to undo his last action.
Is there universal way to undo any function which just finished to work?
Of course, I can do this way:
isTrue=true
num-=5
but that to do if there is many functions? Is there easy way to undo any function (android)?
I don't know any language or platform where you can do something like that.
Any code that your application executes modifies data in memory in some way (creates or destroys objects, changes values etc.). In order to undo changes made by that code operating system should save the full history of data modifications and that is practically impossible because of limited resources.
There isn't any built-in language feature to allow undoing everything that function has changed, but there are patterns that are established in other to help in these kind of situations.
One option you have is memento pattern, where you keep copy of previous state, so that you can always comeback to it, but one drawback of this is increased memory usage for saving all excess state, or in case you are persisting state on disk then there is performance overhead for reading/writing.
Another option is using command pattern where each command knows how to undo itself, this way you don't need to keep previous state, but you need to keep track of command history, what this means is that if you have a lot of state then command pattern would be better option because you don't need to save previous state but you will have a inverse function which knows to undo change that has been made by that command, while if you have only few strings then using memento pattern would be better option, especially if you need to allow undoing actions even after app is killed and started again.
Good example of using command pattern for undo with explanation can be found here.
So I'm attempting to make a one-way wall, that means my actor can pass throw this object only one side (for example only by the bottom side or the upper one).
I began reading this tutorial: one-way-walls
but when I try, after checking the direction of my actor, to disable the collision it doesn't work.
I think my issue could by on this part
Since we will be using BeginContact event which only occurs one time per collision, we can only use SetEnabled once to alter the behavior of the contact. The problem is the contact will revert to being enabled again after each step. We could make a note of which contacts we have disabled and then check the list of them every time in PreSolve, but that is kinda inefficient and more work than I can be bothered with today. Or any day actually :)
So we'll just quietly sneak into b2Contact.cpp and comment out the line at the beginning of the Update function which re-enables the contact. After you're done it should look like this: // Re-enable this contact.
//m_flags |= e_enabledFlag;
The problem is that I'm using a java version of libgdx in AndroidStudio and I have no idea to how find and change this piece of code.
So I need a way to change it, or a different solution to avoid this collision state "re-enabling" at every cycle.
You could solve this in preSolve and store the status (if the contact should be enabled or not) in the fixtures userData. Of course you should revert this flag in endContact.
Please deal with this naive question.
Objective is to create a UI and dynamically be able to change the basic workflows, add another option, add another steps etc.
As an example, one simple workflow could be as following:
What's the age of 'X'? TEXT_BOX
if(age>18) proceed to step 2.
else, go to next page (let's say, same processing happens again with different value of X).
What does 'X do?
a. Job
b. Business
Submit (Go to next 'X').
I wanted to keep this workflow in XML as complete tree (all branches of if/else-if/else) and pass it on UI for rendering. Some of the sub-trees will be populated as per action performed in previous step.
This way, small modifications or workflow changes will not require any code changes.
Other option is to use JSON and pass it directly (rather than converting XML to JSON and passing) but it will be loosely coupled and could be difficult to manage in future.
Is there any clearcut benefit I should think of before choosing any of them?
Will any of them provide any extra benefit in the problem I am trying to solve?
Thanks,
It is possible to mimic the structure that you plan to have in an XML, as a json string, without any hurdles as far as I think of. (If you think of any hurdles please point out, I might help you out with idea to handle that).
json will for sure save you lots of bandwith if the data you are planning to send is large. This will inturn also reduce the roundtrip time and make your application more responsive.
I'm adding in some functionality to a MIDP-based app which requires me to track whether or not an Item has focus. I'm only really concerned with field-style Items and need to determine when the user has finished inputting data into the Item.
I'm aware that CustomItem has the traverse() callback, but I can't find anything similar for classes like DateField, TextField and ChoiceGroup.
I'm also aware of Display.setCurrentItem() but for some strange reason there doesn't seem to be a Display.getCurrentItem() method.
Implementing all the controls as CustomItems isn't really an option as it's a pre-existing app and there are quite a lot of controls to deal with. I can't believe that nobody has run into this issue before, but I've searched on here and google to no avail. Hopefully I'm just missing something obvious in the API, but if there isn't a definite answer then creative solutions are welcome!
In MIDP 2 lcdui API, the only field-style Items are, well, interactive subclasses of Item: TextField, DateField, Gauge.
For above items the closest match to what you are asking about seem to be provided by ItemStateListener (take a look at API javadocs here if you're interested).
...used by applications which need to receive events that indicate changes in the internal state of the interactive items...For implementations that have the concept of an input focus, the listener should be called no later than when the focus moves away from an item whose state has been changed.
If you plan to use this API, carefully check the docs to verify that it indeed gives you what you want - there are some subtle limitations there. If it turns out that you need greater control than that, your options are either to use low level UI (Canvas, events) or 3rd party library like LWUIT, J2ME Polish...
I have a piece of xml that contains optional non-enumerated elements, so schema validation does not catch invalid values. However, this xml is transformed into a different format after validation and is then handed off to a system that tries to store the information in a database. At this point, some of the values that were optional in the previous format are now coded values in the database that will throw foreign key constraint exception if we try and store them. So, I need to build a process in a J2EE app that will check a set of xpaths values against a set of values that are allowable at those spots and if they are not valid either remove them/replace them/remove them and their parents depending on schema restrictions.
I have a couple options that will work, but neither of them seem like very elegant/intuitive solutions.
Option #1 would involve doing the work in an xslt 1.0. Before sending the xml through the xslt, querying up the acceptable values and sending the lists in as parameters. Then place tests at the appropriate locations in the xml that compares the incoming value against the acceptable ones and generates the xml accordingly.
This option doesn't seem very reusable, but it'd be very quick to implement.
Option #2 would involve Java code and an xml config file. The xml config file would layout the xpaths of the needed tests, the acceptable values, the default values (if applicable) and what to take out of the doc if the tests fail.
This option is much more reusable, but would probably double the time needed to build it.
So, which one of these would you pick? Or do you have another idea altogether? I'm open to all suggestions and would love to hear how you would handle this.
Sounds to me like option 2 is over-engineering. Do you have a clear idea about when you will want to reuse this functionality? If not, YAGNI, so go for the simpler and easier solution
Both options are acceptable. Depending on your skills and the complexity of your XML, I would say that it will require about the same amount of time.
Option 1 would be in my opinion more flexible, easier to maintain in the long run.
Option 2 could be tricky in some cases, how to define the config file itself for complex rules and how do you parse it without having to write complex code? One could say, I'll use a dom4j visitor and I'll be done with it. However, option 2 could become unnecessarily complicated imho if you deal with a complex XML structure.
I agree here. It felt like it was borderline over-engineering, but I was afraid that someone hearing that this was done would assume that it would be reusable and attempt to design something that used it in the future. However, I have since been reassured that this is a one-time deal and thus, will be going with the xslt approach.
Thanks all for your comments/answers!