I'm looking for a way to see my local history changes.
Kind of the equivalent way in WebStorm:
Visual Studio Code now offers this in the Timeline view. See Mark's answer.
Or alternatively, if you want a plugin to give you similar functionality, for example:
Checkpoints
Or the more famous:
Local History
Some details may need to be configured because the Visual Studio Code search gets confused sometimes because of additional folders created by this type of plugins. To fix this, you can:
Add the history folder to your .gitignore file.
Change the history folder location in the chosen plugin
configuration.
Configure the Visual Studio Code search to ignore the history folder.
Local File History
Local history of files is now available from the Timeline view.
Depending on the configured settings, every time you save an editor, a
new entry is added to the list:
Each local history entry contains the full contents of the file at the time the entry was created and in certain cases can provide more semantic information (for example indicate refactorings).
From an entry you can:
compare the changes to the local file or previous entry restore the
contents delete or rename the entry
see https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_66.md#local-history
Local file history is being actively worked on and is in the Insiders' Build v1.66. The results will be available in the Timeline view.
Here are the current applicable settings:
Workbench > Local History: Enabled
Controls whether the local file history is enabled. When enabled, the
file contents of an editor that is saved will be stored to a backup
location and can be restored or reviewed later. Changing this setting
has no effect on existing file history entries.
Workbench > Local History: Max File Entries
Controls the maximum number of local file history entries per file.
When the number of local file history entries exceeds this number for
a file, the oldest entries will be discarded.
Workbench > Local History: Max File Size
Controls the maximum size of a file (in KB) to be considered for local
history. Files that are larger will not be added to the local history
unless explicitly added by via user gesture. Changing this setting has
no effect on existing file history entries.
And these commands:
timeline.toggleExcludeSource:timeline.localHistory
workbench.action.localHistory.compareWithFile
workbench.action.localHistory.compareWithPrevious
workbench.action.localHistory.selectForCompare // compare any 2 entries
workbench.action.localHistory.compareWithSelected
workbench.action.localHistory.delete // delete this entry
workbench.action.localHistory.deleteAll // delete all entries of all files from local history
workbench.action.localHistory.open
workbench.action.localHistory.restore
workbench.action.localHistory.restoreViaEditor
workbench.action.localHistory.rename // rename this entry
New global commands have been added to work with local history:
workbench.action.localHistory.create: create a new history entry for the active file with a custom name
workbench.action.localHistory.deleteAll: delete all history entries across all files
workbench.action.localHistory.restoreViaPicker: find a history entry to restore across all files
A bunch of new settings have been introduced to work with local
history:
workbench.localHistory.enabled: enable or disable local history
(default: true) workbench.localHistory.maxFileSize: a limit of
file size to create a local history entry (default: 256kb)
workbench.localHistory.maxFileEntries: a limit of local history
entries per file (default: 50)
workbench.localHistory.exclude:
glob patterns for excluding certain files from local history
workbench.localHistory.mergeWindow: interval in seconds during which
the last entry in local file history is replaced with the entry that
is being added (default 10s)
it's pretty simple, just open a file and check timeline tab
I built an extension called Checkpoints, an alternative to Local History. Checkpoints has support for viewing history for all files (that has checkpoints) in the tree view, not just the currently active file. There are some other minor differences aswell, but overall they are pretty similar.
Basic Functionality
Automatically saved local edit history is available with the Local History extension.
Manually saved local edit history is available with the Checkpoints extension (this is the IntelliJ equivalent to adding tags to the local history).
Advanced Functionality
None of the extensions mentioned above support edit history when a file is moved or renamed.
The extensions above only support edit history. They do not support move/delete history, for example, like IntelliJ does.
Open Request
If you'd like to see this feature added natively, along with all of the advanced functionality, I'd suggest upvoting the open GitHub issue here.
right-click the file and select Show History.
Other day I lost my git changes because I've clicked that graphic undo option of Git.
This option saved me so I could get back my code.
There isn’t any option in Visual Studio Code to see file history. If you are using Git, then you can use Visual Studio Code extension Git History to see the file changes after each commit and compare with previous commits.
Related
I have used WebStorm from JetBrains for almost four years now. It's a fantastic IDE for many reasons, but one of the best features is that it saves versions of files outside of version control. So if you accidentally delete files or lose files before they are saved by your version control system, WebStorm has a copy of them and there are visual diff tools to use. This feature has saved me on more than one occasion.
For Visual Studio Code, is there some feature/plugin that will auto-save copies of files as they change? Will Visual Studio Code save the files to some central location, or perhaps in the .vscode folder in the local workspace?
The feature in WebStorm is available from Local History → Show History from a folder or file. Here is an article about it:
Using Local History for code changes tracking
The view looks like:
You can go to menu File and choose Auto Save.
You can enable auto save with these methods:
Check the Auto Save item in the File menu
Go to Settings, search for auto save, and select the auto save option (afterDelay)
Auto save description in Visual Studio Code documentation
Yes, Visual Studio Code can auto-save changes on files as you make changes. It also allows you set a delay for how long to wait before saving the file.
Here's a link that should help you with that.
Or a shortcut you can simply navigate to your Visual Studio Code settings, and add the following to your settings.json file.
{
...
"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000,
...
}
This will instruct your editor to autosave after a 1000 ms delay. You can set the autosave option to onFocusChange to autosave whenever you move your cursor away from the current text area.
There's a package called Local History that can be used to save a backup of your files outside version control.
You should check that out.
As of March 2022 (version 1.66), Visual Studio Code has a built-in feature called Local History that automatically creates commit-like versions of your files on every save.
It is enabled by default, but you can double check the setting workbench.localHistory.enabled to make sure it is enabled in your project.
From the reference:
Each local history entry contains the full contents of the file at the time the entry was created and in certain cases, can provide more semantic information (for example, indicate a refactoring).
From an entry you can:
Compare the changes to the local file or previous entry.
Restore the contents.
Delete or rename the entry.
The saved local versions are accessible from the Timeline section in the File Explorer tab.
Also, ensure you add .history to your .gitignore file, so Visual Studio Code doesn't track every change made to a single file as changes made to multiple files. This can be a problem and make your files changed so large even though it's a single file or a few files you made edits to.
I try to totally remove Podcasting Plugin by TSG since it generated thousand of useless lines in its settings and in my blog home page.
But if deleting its files is not enough since all settings are stored in wordpress database options table.
Mu question is: how could I delete all these settings in order to start from scratch a new installation?
Thanks.
You need to go into the database directly.
If you're using a MySQL administration tool (e.g. phpmyadmin), go there, search for the settings that it has changed (e.g. if the plugin changed a the web address for the site, you can manually change it back to what you want).
If you don't happen to know exactly what it changed, since it may be difficult to exactly know, if you have saved a previous version of the MySQL database, you could start over and import the old .sql file that you have saved.
I'm thinking of Mask as in a circuit Mask (I think)- let me explain with a handy chart
The common source would be physically in c:\source
Instance A would be physically in c:\instanceA but initially have nothing but symlinks to everything in c:\source
Instance B would be physically in c:\instanceB but initially have nothing but symlinks to everything in c:\source
As you made changes to Instance A and Instance B, you would have create a mask that would hide files from CommonSource if they were deleted from the Instance folders and create a new physical file in the instance directory if an existing Common Source file was modified.
New files would live in the instance folders but never make it back to the Common Source.
This type of setup would be very useful for a project where I want to do many different types of small tweaks to multiple instances where distinct threads would work on distinct instances.
I know about symbolic links but they fall short in the case of modifying a file.
Is there anything that can accomplish this? If not, should I try to make this and patent it? Seems like a good idea to me.
I would be on Windows Server 2008 or later.
Fearing I'm stating the obvious, but git is one tool that can be used to achieve this behavior.
Make your "Common Source" a git repository
Clone the repository twice to "InstanceA" and "InstanceB"
In each instance, check out a new, unique branch
As changes are made in "Common Source" you can merge those changes into "InstanceA" and "InstanceB" while maintaining the "MASK" (changes to the branch) you've created for each.
This has the added benefit of allowing changes from "Common Source" to be pulled as you wish instead of having changes to "Common Source" pushed out to each instance (something I imagine would be less desirable and more prone to error).
You're looking for a union mount. Unfortunately, I'm not aware of any implementations for Windows, but there are several available for Linux, notably UnionFS.
In general they are used for making a read-only filesystem look like it's read-write: typically on live-CDs.
Since Windows 7 you can use libraries, which will allow you to include files from more than one physical location.
Windows 7 also include VirtualStore type of folder (for example, when creating or modifying a file in Program Files folder, it will actually be created in a user specific folder:
C:\Users\user\AppData\Local\VirtualStore. However - I don't know how you can create this type of folders yourself, and also, as far as I know, you can add and modify files, but not delete files in that way.
You'll want a versioning control system that supports per file checkout and permissions. Then you just need to set up a simple API converter that takes file-system commands and converts them to versioning control commands.
Delete -> disable permission to access file.
Directory commands should look for local copies and things you have permission to access.
Open -> grab local copy, on fail check-out file from repository.
Save -> disable permission, save local copy. //Avoid duplicates being seen.
Close without saving -> if permission to access from repository, delete local copy.
((By the way, this storage optimization seems somewhat spurious for versioning. Disk space is relatively cheap.
If your interest isn't in versioning, I'd suggest looking into separating out the information you would potentially want as volatile and creating configuration files for each branch. This, of course, requires a predictable pattern to the changes.))
IBM Rational ClearCase is version control system which does file-mask-like behaviour. It is known as MVFS: MultiVersion File System and can be mount to a workstation like a ordinary network drive.
ClearCase server (aka. VOB) you can store several versions of the same file, each on different code branch. The sets of files visible by user are called views. Each view has a configuration (aka. configuration specification), which defines what files and versions are visible for current user. Typical file looks like this:
# From wikipedia: http://en.wikipedia.org/wiki/IBM_Rational_ClearCase#Configuration_specifications
# Show all elements that are checked out to this view, regardless any other rules.
element * CHECKEDOUT
# For all files named 'somefile', regardless of location, always show the latest version
# on the main branch.
element .../somefile /main/LATEST
# Use a specific version of a specific file. Note: This rule must appear before
# the next rule to have any effect!
element /vobs/project1/module1/a_header.h /main/proj_dev_branch/my_dev_branch1/14
# For other files in the 'project1/module1' directory, show versions
# labeled 'PROJ1_MOD2_LABEL_1'. Furthermore, don't allow any checkouts in this path.
element /vobs/project1/module1/... PROJ1_MOD2_LABEL_1 -nocheckout
# Show the 'ANOTHER_LABEL' version of all elements under the 'project1/module2' path.
# If an element is checked out, then branch that element from the currently
# visible version, and add it to the 'module2_dev_branch' branch.
element /vobs/project1/module2/... ANOTHER_LABEL -mkbranch module2_dev_branch
I'm looking at a scenario where I have an offline clear case view and I modify files in this view clearing the read-only attribute (hijacking) on the files I modify then several days later I take the view online and need to get my offline changes into the stream.
What I would do is check out the hijacked files and check them back in (merging when necessary).
Is it always safe to work this way?
Is it possible that while adding my changes I would accidentally overwrite other people's changes done while I was working offline?
Any recommendations on how to use ClearCase offline?
Thanks!
(I'm asking because a college says that this offline way of working can lead to overwriting other's changes, specifically in cases when one updates ones view after working offline for a while before converting the hijacked files into checkouts. He says it won't event propose to do a merge in some cases, just completely overwrite the contents of the element being converted with the contents of the hijacked file)
No you won't override anything while working offline.
ClearCase has a reconcliation mechanism for a snapshot view, which, when you get back online, will allow you to:
search for all hijacked files
checkout those files
then checkin them, which is when ClearCase will prompt you for a merge, if any new version has been done on that file during your time offline.
That merge will be a three-way merge with:
root version: the version before any modification by you or other
source version: the matest checkin version (done while you were offline)
destination version: your current file
What about setuping a private branch, working on it, hijacking there files and then merging your private branch on the main branch?
Is it possible?
Exporting sources from ClearCase?
The surest way is a snapshot view on a dedicated workstation: since a snapshot view has its storage (the equivalent of the .svn directories) outside the said view, that means the resulting directory is clean.
Then you can take this tree, compress it and transfer it whenever you want, (like a workstation without any VCS)
Use a snapshot view. Update the config spec in such a way that it selects the latest version of all elements from the main branch.
Copy the folder recursively to another folder say c:\svntemp
Import the contents in c:\svntemp\ in to SVN.
For each branch that you have you need to follow this procedure