I'm using WinMerge to compare java files in folders (including subfolders).
I would like to ignore comments when the comparison is done, but I don't know how to do it.
At the file level I've found a switch in the option, so if I compare two files the comments are ignored. However if I compare the folders where those two files live WinMerge tells me that the files are different. Then when I click on the files WinMerge finds out that the only differences are comments and it tells me the files are equal.
Any idea?
You could use a plugin IgnoreCommentsC.dll. The plugin ignores comments within //... and /* ... */ delimiters in C, C++, PHP and JavaScript files.
You could just associate it with java files. Download from here.
EDIT:
It seems that the link doesn't have the plugins downloadable anymore. The documentation says to install plugins at installation time. You can find more information about plugins in the documentation (general info, available plugins)
Related
Sublime Text's Find in Files feature is handy, but I often wish there were a method (or perhaps a plugin I cannot find) to include only files under version control—or, inversely, to exclude files not under version control.
Ideally I'd cherish a <git tracked files> tag, similar to the <open files> and <current file> tags you can use.
Is there a method I could use to achieve this search scope, or a plugin which would allow it?
Sublime's internal Find in Files functionality can be used to search any folder or folders including the ability to add filters to reject or add particular files or file sets, but those filters operate on the path only, not on the contents of the file or any metadata. There is also not an API endpoint for adding new filters to the list or any way for a plugin to interact with the search at all (except to do something to the results once they're generated).
As such, the only way to pull something like this off would be a package/plugin that creates a replacement Find in Files functionality that is more extensible. I'm not aware of any package that does that myself and I've never come across anyone asking about one previously, but there may be something on Package Control that does this.
Depending on your use case you might be able to mostly get what you want by excluding untracked files and/or folders from the search. For example a common notion is to redact node_modules as largely uninteresting in the general case. That's not really a solution to your particular problem, though.
I'm using VS 2012 Extension Web Essentials 2012 and I have some questions about it:
I'm trying to export its settings so they can be shared on other machines. But I can't find any hint on that.
And if it is somehow possible, how can I extend the list of files ignored by jshint. E.g. jQuery.js is ignored but not jQuery.validate.js, so I have a lot of warning of 3rd party files.
EDIT
First question is solved, I had to right click on my solution node in VS, move to Web Essentials and then to choose Create solution settings. I got an XML file that can be checked in into source control and then be reused by other machines.
Second question remains open
Regarding question #2, jshint ignore list in web essentials is currently implemented (hardcoded) as a private static, see the source on GitHub (lines highlighted). Also, parsing .jshintignore files is not currently implemented.
If you want JSHint to skip some files you can list them in a file named .jshintignore. For example:
legacy.js
somelib/*.*
otherlib/*.js
EDIT [[Solution Updated..]]
You can Try this One.
So there is an option to ignore files in jshint, but it's not set within .jshintrc but rather a separate file .jshintignore, which makes sense. However, while jshint will look for .jshintrc in your project's subdirectories, .jshintignore needs to be in the project root. So .jshintrc is in /js while .jshintignore needs to be placed in /.
So to solve the problem in my question /.jshintignore needs to contain:
js/html5.js
js/theme-customizer.js
And that's it!
Referred From This Question
I have just finished my C# Windows form program and would like to make a zip file of the binary so others can download it. I checked the bin/release folder, and while I can recognize many files which I know will be necessary, but some other files I am not sure if it is safe to exclude them.
The following files are the ones I am not so sure:
program.pdb
program.exe.manifest
program.exe.config
program.application
ExternalDLL.xml (related to
ExternalDLL.dll which I need to keep,
but is the xml important?)
P.S. I am using VS Express so I have to manually deploy my project.
The short answer is: You don't need any of those, with the possible exception of the .config file. If you didn't store any of the app's configuration in its .config file, then you don't need it either. I recommend excluding all of them and trying your app on a different machine. I expect it'll work fine.
The longer answer is: There's probably individual SO questions about each. For example, here's a manifest/application question: C# - do I need manifest files?
I could use some advice.
I'm in the process of adopting subversion, and I'm trying to put some existing Visual Studio 2010 projects into a repository. I have the current version of AhnkSvn.
The projects I have are organised as;
VS2010_projects\Project_A
VS2010_projects\Project_B
VS2010_projects\Project_C
VS2010_projects\Common_code
Where Project_A, Project_B and Project_C may all refer to one or more files in "Common_Code"
In visual studio, these files will have been added using "add as link".
There is no actual project in "Common_code" just a collection of useful code files, which we're likely to re-use in different projects.
(If we have a module or class which is re-used in various projects, then we often keep a single master copy in 'common-code', and link to it.)
Visual Studio has no problem with this.
When I add any of the actual projects to subversion, all of their own files are added just fine, but the linked files are ignored.
(And as a consequence, if I then get a working copy of those files, then it's just the project files which get handled, I won't get a copy of the linked files.)
If I right click on any of the linked files, I the only subversion options I get are to refresh their status or to select the working folder.
I was wondering what the correct way to handle this situation was ?
Any advice would be much appreciated
Thanks !
Robert
if I understand your question correctly then I think SVN is acting in the desired way. A linked file is merely a reference to another file. That reference exists only in the .csproj file which is checked in. It would not make sense to have two copies of the same file in source control, and it could lead to versioning issues. The first time you checkout your repository doing a build on your projects should copy the files from Common_code to the places that they're linked.
As an aside we've had alot of random issues with .csproj linked files and SVN, and so try to avoid linked files where possible. A better way to re-use files across projects is obviously just to embed them in a library and then reference that library. This should work fine with the exception of certain files like Javascript/CSS.
Also you may want to check out SVN externals, a workmate mentioned this can be used to share common libraries between multiple projects, although as a disclaimer I haven't tried this myself and can't comment on the merits or drawbacks of the approach.
Thanks for the advice, I actually did something similar to your suggestion.
I didn't want to make a full blown library, but I did make up a dummy project, and put my shared files into that.
Then I added the dummy project to the repository.
AhnkSvn now seems to be satisfied that the linked files are under subversion control, and seems to handle them just fine.
(I haven't added any reference to the dummy project to my existing projects - they just use the linked files as before - but now AhnkSvn shows me their status, and allows me to get the latest version, and commit changes.)
I can see the case for having a proper library - but that would have meant modifying a large body of existing projects. This approach lets me get up and running with Subversion without requiring those changes first.
I am building a cross platform product and one of the requirements is across windows(win32,AMD64 and IA61). The product as is relatively simple CLI but we have a separate build team who checks out the code from CVS and build in separate build environments. I am able to build succesfully(using Visual C++ 2005) in one platform(AMD machine). But once I check in the code, check out the build fails.
The cause of the build failure is because the include library paths are wrongly specified in the property sheets. Specifically the output file folder under the Linker in property pages are specified wrongly. So these libraries get built in a different folder from where the other projects are expecting them.
However along with the source I check in the .sln files (and later .vcproj files) also everytime. Morover if I open the .sln file in the folder where the build is not succeeding, there is no difference between the one where I could succesfully build(pre check in). In fact using windiff I could not see any difference between the two build folders (except some .ncb and cvs log files).
So any idea what is going on? Where does VC++ 2005 take the include directories take the output folder path from if not from .sln? Is CVS somehow interfering with the process? Anything else I could try out.
Thanks in advance.
Just to update the problem was resolved. The root cause is the .vcproj files were not getting checked in CVS!! This is where the individual project settings were stored(I was under the impression that this is done in .sln files).
I think the problem can be that after you have changed the settings in one build configuration (for example x86-Release) but forgotten to change them for another configuration (for example ia64-Debug), and when configuration changes, you have this problem.
Another thing that I would check on your place is project dependencies. If those are set in the right way VS will look for project output exactly where it is outputted, even when you change the output folder.
Do you have any binary files checked in as ASCII?
The round trip to and from CVS can corrupt binary files that are incorrectly marked as ASCII because CVS performs character processing on ASCII files (e.g. to give you the correct end of line codes for your OS). Corruption can occur even in an all Windows environment.
See the Binary section in the CVS FAQ for more information.