Can some one help me how to configure WinMerge as RTC's compare editor?
My friend used BeyondCompare however I am more comfortable with WinMerge.
This thread does mention:
I've always used WinMerge. Beyond Compare is also a good compare tool but it's not free.
You can configure RTC to use another compare tool in Windows > Preferences > Team > Jazz Source Control > External Compare Tool.
There are defaults configurations for both the tools listed above or you can enter a path for you own compare tool.
See more at "Can I use any other diff/merge tool, other than the one provided in RTC?"
(the picture shows "BeyondCompare", but there should be WinMerge as well in the dropdown list)
We have pre-configured some popularly used compare/merge tools like Beyond Compare, DiffMerge, P4Merge and WinMerge.
Related
I'm writing my first KDE plasmoid using QML. The hello world example uses a metadata.desktop file, while this KDE Plasmoid tutorial talks about a metadata.json instead and says that the metadata.desktop is 'discouraged' now and a desktop file should be converted to json using desktoptojson.
However, when I browse the globally installed plasmoids under /usr/share/plasma/plasmoids/ they all have both the metadata.desktop and metadata.json.
First question: So, what is really recommended? Just the metadata.json? Or both?
And, I wasn't able to find the desktoptojson tool. I'm using Linux Mint and the ./kdesrc-build --initial-setup for debian based systems says that it's "This is woefully incomplete and not very useful" ... I read that "most users of this [i.e. desktoptojson] utility will use the CMake macro kservice_desktop_to_json as part of the process of building a plugin.". However, I haven't found the documentation yet how to use this.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
Thanks!
First question: So, what is really recommended? Just the metadata.json? Or both?
In the current source code, most stock KDE applets such as the task manager use metadata.json's and have dropped the metadata.desktop's. It may be that the desktop files you have locally are left over from old versions, the new format was installed but the old one was never deleted.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
The man page on Arch you linked to has all the information. The tool is part of the package kservice. Find the equivalent in the repository for your distribution. Then, to use it
as part of a CMake macro:
add_library(myplugin MODULE ${myplugin_SRCS})
kservice_desktop_to_json(myplugin myplugin.desktop)
directly on the command-line:
desktoptojson -i myplugin.desktop -o myplugin.json
I love the JetBrains tools. But, I can't find a way to effectively share settings at the IDE level and the project level with team members. To date, I've followed instructions provided by an article on the JetBrains site, titled "How to manage projects under Version Control Systems". But, many comments on the article warn against implementing it as a method for sharing project settings. And I've run into a few issue with the method, namely not everything I'd like to be shared, is actually shared with team members.
I've also tried using the function found under the File->Settings Repository menu of the JetBrains tools. It shares some settings between users, and I like that it automatically creates commits to the Git repo, but it doesn't share all the settings. The settings that are shared work great! But, it seems like the "Settings Repository" feature is a work in progress.
I've read many discussions on this topic, but no definitive answer on a way to share IDE level settings and, at the same time, project specific settings when using the JetBrains tools. Not to mention, I use a multiple JetBrains tools (PhpStorm, PyCharm, WebStorm and IntelliJ). I'd like it if there were a solution that also shared settings between all the tools, because some settings are global across all JetBrains tools, some are specific to a particular tool, and some are specific to a project.
Sharing settings between JetBrains tools is more of a "nice to have". What I really need to know is, how can I share global IDE settings and project level settings easily between team members. But, I'll give mad respect points to anyone who can figure out both. :-)
I finally found a few minutes to write up an answer to this. I want to write up a more complete answer, but I've been incredibly busy lately so this will have to do for now.
This solution describes what I've been using to share code and settings of PyCharm projects. There is one caveat to this solution, which I'll attempt to describe and detail a work-around for.
Following the instructions on JetBrain's knowledge-base, we'll add the entire project folder to a Git repo. But, before doing so, be sure to exclude at least the workspace.xml file by creating a .gitignore file in the project directory and add at least the following line:
.idea/workspace.xml
# JetBrains also recommends adding tasks.xml, but I found it useful to
# share tasks with team members.
# Uncomment the following line to avoid sharing tasks with team members
# .idea/tasks.xml
You'll definitely want to add workspace.xml to .gitignore because it stores all of your local window sizes, debug panel layouts and the like. My team found it useful to syncronize our tasks, so that we could coordinate work. But, every team works differently, so use your own discretion.
There are three main locations project and personal preferences are stored:
<project_directory>/.idea contains project specific settings.
$HOME/.PyCharmYYYY.M/config contains options for all projects managed by PyCharm (or substitue "PyCharm" for any other JetBrains tool).
If you use the shared settings found in File->Settings Repository, $HOME/.PyCharmYYY.M/config will contain all of the settings shared via JetBrain's built in "shared settings" function. I and my team didn't care for it, because it seemed to automatically share some things we didn't want to (like the color theme, and key mappings). And we weren't able to select a sub-set of options to share team-wide. Long story short, it didn't give us the flexibility and control we need.
We did try using options 1 and 3 at the same time, but it was too unwieldy. For example, one person would change a font, and it would change it for the whole team the next time we re-launched JetBrains. It was a mess. If you do decide to try out using options 1 and 3, I recommend proceeding with extreme caution.
Presently, we are using only option 1, and it's working out quite nicely.
A few other notable folders you might want to add or remove from the .gitignore file are:
<project_folder>/.idea/runConfigurations/ contains all of your debug and run configurations used to run nose tests and debug into your code.
<project_folder>/.idea/scopes/ contains all of the scopes used to filter your view of the project files, into more management groupings.
$HOME/.PyCharmYYYY.M/options contains all of the global options for version of PyCharm you're using. For example, the color scheme, key mappings and any other non-project specific options. For a full list of other global settings, see this JetBrains article, or the following excerpt:
I am installing an major upgrade of product in my system.
Folders and registry entries will be updated for this.
I would like to take snapshot of folder structure and registry before/after installing update so that i can compare them easily.
Is there any tool or simple powershell module available to do this?
I hope testers would have done this while doing installation testing. If you have followed any good approach ,please update us.
One of the best tools I've come across for before/after registry comparisons is called RegShot:
http://portableapps.com/apps/utilities/regshot_portable
The 1.8.3 version supports 64 bit registries:
http://sourceforge.net/projects/regshot/
Yet another tool is called ZSoft Uninstaller:
http://portableapps.com/apps/utilities/zsoft_uninstaller_portable
This one is tailored toward software installation analysis.
Both of these can perform registry and file system before/after comparisons.
Well, practically, I think you'll have to limit the paths you want to "monitor". You can use the PowerShell provider for registry very easily. For example:
Get-ChildItem -Path HKCU:\SOFTWARE -recurse | Out-File HKCU_Software.reg
More information here. Then, you can make a diff (before, after) using a tool like DiffMerge. Same principles for directories.
However, once again, beside a shallow check, I don't think that approach is realistic.
Don't know your context, but Microsoft's Attack Surface Analyzer might be useful.
I recommend RegistryChangesView by NirSoft.
It could be particularly good for you as you mentioned PowerShell modules in your question, and RegistryChangesView has documented command-line options. RegistryChangesView also supports exporting the comparison to a .reg, HTML, or CSV file etc.
I'm still looking for a tool that can directly output the difference in the form of PowerShell commands; until then, I can export to a .reg file and then run it through a .reg-to-PowerShell-commands converter.
Other options include the classic Regshot which has also been forked as Regshot Advanced. However, personally, I go with RegistryChangesView because I think it has better documentation/command-line options.
I currently use Programmer's Notepad with the Rebol syntax scheme. It's not bad--does any insightful person have another suggestion?
For my Windows programming work I use the Zeus editor, but I'm not sure if it does Rebol?
Another windows option is TextPad. It is commercial but it is quite a useful editor.
There are 2 Rebol syntax files available from the official site
http://www.textpad.com/add-ons/synn2t.html
I also wrote a TextPad syntax file generator uploaded it to rebol.org
http://www.rebol.org/view-script.r?script=textpad-syngen.r
It is probably quite easy to modify this script to support other editors.
vim.
Especially with the following binding in your _vimrc/.vimrc:
nnoremap <Leader>fr :w<CR>:silent ! %<CR>
In normal mode, Leaderfr saves your current file and executes it: (fr is a memo for 'fast-run')
:wEnter save current file
:silent execute without messages: ! open shell % paste current file name Enter
Leader is usually \ key, I have this mapped to spacebar. In case anyone is interested on how to do that, post a comment.
Programmer’s Notepad better than Crimson Editor with Code Folding and Great Project Management
http://www.pnotepad.org/
It's opensource so you can even modify it in C++
For Windows, there is Crimson Editor or E with the REBOL bundle.
For Mac, there is TextMate.
Emacs, I believe has a REBOL syntax too.
Sublime Text is a really nice Windows editor (commercial, but reasonably priced) that supports TextMate configurations (well, at least for syntax and snippets) so if you manage to get a REBOL bundle from somewhere, you can use it with this.
SciTE also has REBOL syntax coloring support because the Scintilla editor component it's based on includes this.
Notepad++ should also support REBOL syntax coloring, being Scintilla based, but as it is currently distributed, the support is not compiled in. If you're so inclined, you could probably compile it yourself and add the support back in. It might be worth it because Notepad++ is quite a good editor too.
I can't include proper links because I don't have enough rep, but this should do:
www.sublimetext.com
www.scintilla.org/SciTE.html
www.scintilla.org/index.html
notepad-plus-plus.org
http://rebol.wik.is/index.php?title=Notepad%2b%2b
which is a REBOL plugin for Notepad++
I use JEdit which not only has REBOL syntax highlighting but also auto-indenting. It has most of the features you'd expect from a text editor (e.g. block selection, configurable keyboard shortcuts).
There are versions for Windows, Mac OS X and Linux so if you choose to work cross-platform you won't need to learn a new editor. The web page is Jedit.org1
I use UltraEdit.
with its advanced project, syntax highlighting, macro, command-line control and total keyboard shortcut configuration, per language and project, you can program the editor to do just about all of what you need at a single click of the mouse, or keyboard.
my setup starts rebol on any file, and assigns a launch "default project script " to a shortcut, so wherever I am in the files, I still launch the project's relevant script. change project, it will run that new project's scripts. another key for unit tests, another key for "find in all opened files, etc, etc..
also, the actual text-exiting, when combined with a few macros which create functions, objects, and more using the clipboard and "currently highlighted" text makes it much faster than any Visual IDE including MSVC.
ultra edit itself has thousands of other advanced features, and they all work... really they do.
I've tried other editors and they always fall short when I start to push them.
yeah, you have to buy it... but its cheap (like one or two hours of your life salary ;-)
so considering you might use it for several months or years... its a cheap investment.
also, ultra edit is now released on linux and the mac port is just around the corner.
I use EditPlus for several years, it is not free but not expensive. It has Rebol syntax highlighting file (downloadable from its web site).
It is especially useful & very fast if you work with huge files (over 100 mb) or with lots of files (say 300 files.), find & replace takes a second.
For syntax highlighting and a simple autocomplete, you can use http://komodoide.com/komodo-edit/.
It's free and open source with several nice features, including folder browsing while editing, which I personally find very useful.
There is also a bunch of other languages supported in case you want to take a closer look and give this editor a chance.
The organization I currently work for an organization that is moving into the whole CMMI world of documenting everything. I was assigned (along with one other individual) the title of Configuration Manager. Congratulations to me right.
Part of the duties is to perform on a regular basis (they are still defining regular basis, it will either by quarterly or monthly) a physical configuration audit. This is basically a check of source code versions deployed in production to what we believe to be the source code versions in production.
Our project is a relatively small web application with written in Java. The file types we work with are java, jsp, xml, property files, and sql packages.
The problem I have (and have expressed but seem to be going ignored) is how am I supposed to physical log on to the production server and verify file versions and even if I could it would take a ridiculous amount of time?
The file versions are not even currently in the file(i.e. in a comment or something). It was suggested that we place visible version numbers on each screen that is visible to the users also. I thought this ridiculous also, since the screens themselves represent only a small fraction of the code we maintain.
The tools we currently use are Netbeans for our IDE and Serena Dimensions as our versioning tool.
I am specifically looking for ideas on how to perform this audit in a hopefully more automated way, that will be both accurate and not time consuming.
My idea is currently to add a comment to the top of each file that contains the version number of that file, a script that runs when a production build is created to create an XML file or something similar containing the file name and version file of each file in the build. Then when I need to do an audit I go to the production server grab the the xml file with the info, and compare it programmatically to what we believe to be in production, and output a report.
Any better ideas. I know this has to have been done already, and seems crazy to me that I have not found any other resources.
You could compute a SHA1 hash of the source files on the production server, and compare that hash value to the versions stored in source control. If you can find the same hash in source control, then you know what version is in production. If you can't find the same hash in source control, then there are untracked modifications in production and your new job title is justified. :)
The typical trap organizations fall into with the CMMI is trying to overdo everything. If I could suggest anything, it'd be start small & only do what you need. So consider any problems that you may have had in the CM area peviously.
The CMMI describes WHAT an organisation should do, but leaves the HOW up to you. The CMMI specification, chapter 2 is well worth a read - it describes the required, expected, and informative components of the specification - basically the goals are required, the practices are expected, and everything else is informative. This means there is only a small part of the specification which a CMMI appraiser can directly demand - the goals. At the practice level, it is permissable to have either the practices as described, or acceptable alternatives to them.
In the case of configuration audits, goal SG3 is "Integrity of baselines is established and maintained". SP3.2 says "Perform configuration audits to maintain integrity of the configuration baselines." There is nothing stated here about how often these are done, or how long they may take.
In my previous organisation, FCA/PCA was usually only done as part of the product release process, and we used ClearCase as the versioning tool, with labels applied across the codebase to define baselines. We didn't have version numbers in all the source files, nor did we have version numbers on all the products screens - the CM activity was doing the right thing & was backed up by audits, and this was never an issue in any CMMI appraisal.
We could use the deltas between labels to look at what files had changed, perform diffs to see the actual code changes. An important part of the process is being able to link those changes back to either a requirement/bug report/whatever the reason was which initiated the change.
Our auditing did use scripts to automate the process, but these were in-house developed scripts are specific to ClearCase - basically they would list all the files, their versions in the CM system, and the baseline/config item to which they belonged.
can't you use your source control for this? if you deploy a version and tag your sourcecontrol with that deployment, you can then verify against the source control system