We are currently restructuring our source control. I moved a branch and now all history seems to have been removed. I would like to rollback the branch to a previous changeset. Is there a way to still be able to rollback a branch that has been moved? I'm a newbie to TFS administration so any help would be greatly appreciated.
My findings are as follows:
If your folders are contained within a Parent folder you may still roll back any changes based upon the parent folder's history. Otherwise history is lost upon moving a branch to a new location.
Hope this helps someone down the road.
Thanks!
Related
I'm still getting the hang of VS Code.
I want to make a react app using 2 different GET API URL endpoints but the exact same UI. In essence, I want to change just the base URLs between the 2.
I've tried creating a new branch in VS code to make 2 separate files but once I make edits in the master branch, the changes reflect in the new branch also.
Is there a way of making a different stand-alone branch from the VS code?
I've searched through the forums to no precise avail and I'm not that good at git. Thanks.
It is likely that your changes are being shown when you switch branch because you haven't commited your changes to a branch before switching.
Let's say you are on the master branch and make some changes. You can create a new branch new-feature and change your current working branch to new-feature bringing your existing changes across. This is useful because sometimes you will start to carry out some work before realising the scope is a bit too big and should be it's own branch.
If you want to keep the changes you have made on your current branch, you need to "stage" your changes with git add your_filename.here (or git remove). Once you have added and removed all changed files you want to keep on that branch, you need to git commit them. This is the step that finally adds the changes to the version history.
Now when you change to new-feature branch, your changes on master will not be there.
There are a number of GUI applications that make the git model more intuitive such as SourceTree, Github Desktop, and SmartGit
We want to clean up our database schema and drop/delete objects which are no longer being used.
We suspect that sometime in the future we'll want to resurrect the removed functionality.
We've discussed the following options for dealing with dropped objects in version control:
Deleting the .sql files from source control once they are gone from the database and relying on the version history to store the definitions. Our concern with this approach is that sometime over the years source control will be moved and we will lose the history. It also seems difficult to know what to look for to recover if we can't see all the dropped objects.
Leaving the .sql files in source control but updating the definitions to "drop proc {someproc}". With this approach we our concerned about leaving the objects in version control which no longer exists and also the risk to losing the history if the vcs was moved
Creating a new repo for dropped objects and migrating .sql files to this repo once they have been dropped from SQL Server.
We're working in a windows environment and are fairly new to working with VCS for databases. Currently GIT + SSDT.
Currently option 3 is our preferred approach.
I see this a lot with database code, what happens is over time people end up with stuff in the database that is either not used or just does not work (think a proc that references a table and the table is modified but not the proc).
The thing to do is to get everything in source control (which it looks like you have) and then create a tag or branch of all the code before and after deleting it so you can get it back.
Two things normally transpire, either the code was genuinely never used or it was used at year end and when you find out, the world is about to fall on your head so better have a quick way to get it back.
Of course if you had a full suite of tests then even the year end process would be safe :)
I personally wouldn't use option 3, I would just keep the history in the main branch so you keep the history with it.
ed
There are a lot of good tools for versioning database changes: you have a big chance to get this question closed with "Too broad" reason, but I'll try to suggest to
Read about, understand and try to add Liquibase to your Development-Toolbox
Adopt your workflow for using this additional layer - technically it will be one more file (changelog in terms of Liquibase) in changesets, where you changing DD and|or data.
These changelogs provide good and smooth way of moving back and forth in linear history of changes in databases, not so good (or I don't know The Right Way) for direct jumping between nodes of diverged history, but it seems not your case
From your options-list it will be more p.1, than others (but it's storing changes in database in version-contol, not states)
Just to note another option, in SSDT you can mark the file property as Build Action = None. The file won't be included in the dacpac when this build option is selected. But I tend to agree with the idea that you should rely on your VCS to handle history.
I take care of a couple of extremly large projects. These projects are also divided into smaller del-projects some are delivered as a large project at one time. The problem I am having is that when all these small projects are merged into our release branch its dam near impossible for me to rollback 1000's of files.
I am currently rethinking our branching strategy. Everything now is being merged with a label. We are also merging everything to a build-test branch before we even think about dumping it into our release branch.
If I need to do a rollback based on label what is the best way to do this? I have a few scripts but can't get this to work.. hopefully some ClearCase god here can help ASAP!
Thanks!
Dave
If you need to rollback to a label, you can:
create a dynamic view
edit its config spec to select said label
use that dynamic view as source for a clearfsimport into your main view (the one with the latest releases)
A clearfsimport -rmname ("mirror") will update/add/remove the files in the destination view with the files from the source (which is, here, your dynamic view set to the label you want to rollback).
I modified a page layout in our QA environment using Apex and didn't refresh from the server (my last refresh from the server was 10 days ago). Someone else made a TON of changes using the web interface in between then. I just overwrote all of her changes!
Does anyone have any advice on how I can undo my changes and go back to hers?
Unfortunately there's no tracking of layout changes so there's no way you can just revert this — are there any other developers who may have had a later copy of the metadata and haven't refreshed theirs yet?
It can be a good idea to use ANT to run a metadata backup system so that things like this don't cause problems :) There's a guide to using the Force.com Deployment Tool here, essentially you just want to use half of that process on a regular schedule.
I am trying to use git as something it wasn't made for - a database. Please feel free to tell me that this is a stupid idea.
Setup
One branch (let's call it robot) is being updated automatically by a script on a daily basis. The data comes from some other publicly available database.
Initially the master branch is the same as the robot branch.
Some of the data in the publicly available database is wrong, so I'll make a commit to the master branch and correct the error.
When the script detects any changes on the public database in the future, it will add those to the robot branch as a new commit (there's one commit per file).
Keeping track of differences
Now, I've obviously lost the ability to do a fast forward merge if I've modified the same file. But I could still cherry pick the good changes in the robot branch and import them into the master branch. The problem is that this might get rather messy after a while, when almost all the files have diverged.
How can I keep track of the difference between the different branches in a systematic way?
It sounds like you're looking for the git rebase command. This command allows you to update changes you've made to your master branch on top of the new head of the robot branch:
git checkout master
git rebase robot
There may be conflicts, if the database has been updated with a change to something you've changed in master. You must resolve those conflicts manually.