As part of code review I need to look at the code changes in the order in which they were done. Some colleagues sometimes commit up to 5 changes before YouTrack fetches them. On the depending issue they are sorted by fetch date which I'm not interested at all.
Is it possible to change the sort order? If so - how?
Related
Could anyone provide any best practices about multiple migration runs? Moving from TFS 2017.3.1 to Azure DevOps Service. Dealing with a fair number of work items (32k). Of course, TSTU throttling is making the run take a long time, so I was thinking of pushing what I could up front, then a second pass to pick up the new work items since the first big push. So...enabling UpdateSourceReflectedId would set the ReflectedWorkItemId on the source items that have already been migrated. But what happens if someone changes a work item that has already been pushed? Would the history delta get picked up? How is that typically resolved...I was thinking maybe a Querybit like: ReflectedWorkItemId <> '' and ChangedDate > (last run time), but is that necessary? Those already exist on target...would ReplayRevisions pick up only the missing changes? TIA...
I usually do the following for large runs:
Open work items edited in last 90 days
Closed work items edited in last 90 days
open out to more days in chunks
The important thing to note is that links are created only when both ends of the link exist.
After a long run you can then rerun "edited in last month" to bring any changes a cross.
Changes to avoid in the Source:
changing work item type
moving work item between team project
We handle these, but loosly.
So just like how intellij shows you uncommitted changes in this format Uncomitted change
Is there a way to show last commit changes in a similar way? i know show history option exist but then clicking on every method to see history is kind of cumbersome.If a plugin exist for it then that would also be very helpful.
You can use "Annotate" feature in order to see when changes were committed.
Also you may find this and all related tickets convenient, so please feel free to vote:
https://youtrack.jetbrains.com/issue/IDEA-190536
What should I do if a user has a few hundred records in the database, and would like to make a draft where they can take all the current data and make some changes and save this as a draft potentially for good, keeping the two copies?
Should I duplicate all the data in the same table and mark it as a draft?
or only duplicate the changes? and then use the "non-draft" data if no changes exist?
The user should be able to make their changes and then still go back to the live and make changes there, not affecting the draft?
Just simply introduce a version field in the tables that would be affected.
Content management systems (CMS) do this already. You can create a blog post for example, and it has version 1. Then a change is made and that gets version 2 and on and on.
You will obviously end up storing quite a bit more data. A nice benefit though is that you can easily write queries to load a version (or a snapshot) of data.
As a convention you could always make the highest version number the "active" version.
You can either use BEGIN TRANS, COMMIT and ROLLBACK statements or you can create a stored procedure / piece of code that means that any amendments the user makes are put into temporary tables until they are ready to be put into production.
If you are making a raft of changes it is best to use temporary tables as using COMMIT etc can result in locks on the live data for other uses.
This article might help if the above means nothing to you: http://www.sqlteam.com/article/temporary-tables
EDIT - You could create new tables (ie NOT temporary, but full fledged sql tables) "on the fly" and name them something meaningful. For instance, the users intials, followed by original table name, followed by a timestamp.
You can then programtically create, amend and delete these tables over long periods of time as well as compare against Live tables. You would need to keep track of how many tables are being created in case your database grows to vast sizes.
The only major headache then is putting the changes back into the live data. For instance, if someone takes a cut of data into a new table and then 3 weeks later decides to send it into live after making changes. In this instance there is a likelihood of the live data having changed anyway and possibly superseding the changes the user will submit.
You can get around this with some creative coding though. There are many ways to tackle this, so if you get stuck at the next step you might want to start a new question. Hopefully this at least gives you some inspiration though.
Presently, I'm tracking changes to all of my tables using SQL Server 2008 Change Tracking. Everything works out of the box just fine. However, an additional complexity is that the application reading these changes needs to make a change to a date column on each table that is being tracked. Changes in my application are like triggers to tell me that I need to send out additional data. This could cause an endless cycle if not managed.
There's a sent date that gets filled in after each change is read.
Is it configurable at a database/table level to ignore an individual column on a table so that versions/changes are not tracked when that column is modified?
Using change tracking, there's two ways but both involve merely filtering the results; there is not a way to limit the change tracking by column.
1) Filter by context
The following link shows how to change the context for when an application changes data. If you change the context specific to what is making the changes, you can then filter it by that when you query. http://msdn.microsoft.com/en-us/library/cc280462(v=sql.105).aspx
2) Filter using the columns updated mask
In addition, I have to admit that I roll my own change tracking still. I have scripts that I execute to autogenerate code triggers. They can be customized to prevent non-changing updates (i.e. a row update that changes no fields you are interested in), plus they allow me to fully control things. I can track which fields I want, plus I can move all of my tracking/default fields (such as suser_sname()) into the tracking table so that the day to day business tables are kept slim. If you are interested in this option, reply as such and I'll post the code to autogenerate the triggers and tracking table for a given table name.
How do I undo an update in Accurev? I want to revert to a state where contents of the files are exactly how it was before an "update" operation?
There are numerous ways to change the contents in your workspace to reflect an earlier configuration. Based on the limited description where you reference "all the files under CM", I'll make the assumption that you want to roll back your entire workspace as opposed to a select few files.
Question: does everyone parented by the same stream as your workspace want to roll back, or just you? If it's everyone, you can change the time basis of that parent stream to reflect the specific point in time you want to revert to. Once that is done, run Update, and you're good. If it's just you and it's more than a small sampling of files, I'd suggest creating a personal time-based stream, setting the time to when you want, and re-parenting your workspace to it:
Current_parent -- New_personal_time_stream -- your_workspace
There are other options as well if you just want to deal with a few select files, but it seems like this is what you're after...
Cheers,
~James