We have a feature (that contained some DB migrations and 50+ changed files) that was merged into master a few commits ago. The powers that be now want that whole feature removed.
There have been no new migrations since this feature was added though there have been some new commits that we want to keep.
What's the best way to unwind this quickly, assuming small team and OK to force push to origin? Is it possible (read: recommended?) to:
rollback the migrations to the point right before this feature (PR) was merged
revert the git commits back to the same point
replay the more recent commits (by hash?) we want to keep (unrelated to the unwanted feature) back on the codebase
This will wreak havoc with other developers but we're a very small team at the moment and working together on this.
Or maybe there is a better way?
I realize rollbacks & reverts are covered in other topics here, and I've read many of them, but our situation is somewhat different as we want to rollback, revert and then replay certain commits and then bring origin up to date so it appears as though that bad feature never happened (or if easier, a merge commit reverting that feature PR would be acceptable).
Thanks for any help!
I'd suggest to add single migration that has code to revert all those 6 obsolete + 1 revert feature merge.
This way you'll
still have it in git history in case there'll be need to reapply, or reuse part of functionality
won't need to be too smart to safely reset git and DB to some state on each dev env + staging/production - which will avoid human mistakes
Related
What is the method for removing inactive, unwanted node labels in a Neo4j database (community edition version 2.2.2)?
I've seen this question in the past but for whatever reason it gets many interpretations, such as clearing browser cache, etc.
I am referring here to labels actually contained in the database, such that the REST command
GET /db/data/labels
will produce them in its output. The labels have been removed from any nodes and there are not active constraints attached to them.
I am aware this question has been asked in the past and there is a cumbersome way of solving it, which is basically, dump and reload the database. The dump command doesn't even contain scattered commit statements and thus needs to be edited before executing it back. Of course this takes forever with big databases. There has to be a better way, or at least there is a feature in the queue of requirements waiting to be implemented. Can someone clarify?
If you delete the last node with a certain label - as you've observed - the label itself does not get deleted. As of today there is no way to delete a label.
However you can copy over the datastore in offline mode using e.g. Michael's store copy tool to achieve this.
The new store is then aware of only those labels which actually are used.
We have an application which has historically suffered a high number of branches.
These have now been ratified, but a situation has now occurred where we have two development streams (which ideally would be one) and one of these streams requires a number of changes where implementing them will have knock on effects which aren't fixable as part of a single story (or possibly a single sprint).
For example: a high number of database schema changes which require a large number of query logic changes.
These changes aren't easily feature flagged as they systematically break existing functionality until the work if completed. We could theoretically put the system back in a 'building' state, but it would prevent the customer from using the existing functionality.
To cater for this, we're proposing creating a new branch for the 'breaking changes' so that the other development stream isn't broken and can be released intermittently.
Whilst I'm loathed to create new branches, I can't see a better way of doing this at the moment.
Is there a recommended practice, either branch strategy to manage or architecturally to protect from, breaking changes in parallel development?
EDIT: The only other thing which has crossed my mind is to literally 'copy-paste' the existing functionality (including tables/web pages etc) renaming them and working on that in the same branch, behind a feature flag.
This is obviously pretty messy for a number of reasons!
Does anyone have any suggestions for how they have coped with this in the past?
You should deliver the database schema (and other changes) in an incremental fashion. Don't take on the whole change at once, but instead break it down into things that you can deliver.
If your current application architecture does not support this model then that is the first problem to tackle.
Always meet your DoD for every Sprint. All work integrated with no further work required to ship...
We are using Team Foundation Server 2010 at work and all of our assignments come from TFS tasks.
Right now I have 2 tasks that relate to the same source file. They are two separate feature requests, but I will end up writing common methods for both. I check in the code changes and link the task when I am finished with the task.
There's an issue right now though with the test database that is prohibiting me from actually finishing off on the first task and checking it in. Well the next task is on the same file.
I am curious how other people handle this issue. I know I could shelve the change and work on the other, but I kind of need some of the other methods I wrote in the first task. The body in some of these methods will be changing a little bit to handle the next feature.
Do I shelve my changes, copy my methods over and modify them for the new task? If I do that, how would the merge process work when I un-shelve my changes? How do any of you handle this issue? Am I better off just doing both tasks in the same changeset? However, now the 2nd task has a dependency on the 1st. If for some reason the database doesn't get fixed, that first task is now holding up the 2nd task from being deployed.
Thanks for your input in advance.
If both tasks are destined for the same release, work on them in the same branch, and just associate both task workitems with the checkin. If they are fundamentally separate changes, and my move to the production codebase separately, then you should have two separate branches for the code.
The reason I'm asking is that I want to test something, that I expect will generate a number of commits, totalling a lot of data, and since it's only a test, I don't want to leave them permanently in the database.
Do I have to set up a temporary TFS server for this, or can I just delete the project afterwards and expects its disk space to be reclaimed?
Disk space will not be reclaimed by normal deletion. You always have the option to undelete something in TFS, so changes will never get lost. (It's kind of a good feature in a source control system).
Do remember that TFS stores files as diffs between commits, so the disk space usage might not be so large as you expect.
You can, however, use tf.exe destroy to permanently delete your changes. I think this will allow you to reclaim disk space (though I haven't tested personally). Please be cautious if using tf destroy.
I got the 'resolve' dialog in TFS, and it looks like I clicked too fast on the wrong button (because they're too close together) and blew away a week's worth of work when TFS discarded my local changes. Is there an undo operation somewhere?
No, sorry. There have been many proposals over the years to move undone changes (and deleted files, etc) to the Recycle Bin instead of blowing them away, but the feature always seems to land on the cutting block. I'll see if there's an open request # Connect where we can add our votes.
PS: shelve early, shelve often!
No, there is not. If you have overwritten your local files, changes are lost.
Sorry (and hopefully, I'll be faster when rewriting your code :))