I'm trying to compare files between two labels with cleartool but I can't seem to figure out how to find the preceding label to the label given.
As for now my command looks like this
cleartool find . -element "{lbtype_sub(TEST_APP_123456-80_1.1.C.004) &&
lbtype_sub(TEST_APP_123456-80_1.1.C.005)}" -type f
-ver "{lbtype(TEST_APP_123456-80_1.1.C.004) && !lbtype(TEST_APP_123456-80_1.1.C.005)}"
-exec "cmd /c copy %CLEARCASE_PN% C:\diff"
In this case the preceding label is provided but it would be nice if cleartool could find it by itself by just providing the latest label.
A label can be applied, and even moved to any version.
Unless you are talking about UCM baselines (in which case a "cleartool diffbl -pred a_BASELINE#\apvob" can give you the previous baseline, from which the label is named after), you cannot find the previous label.
All you can do is to walk back from the version referenced by a label until you find another (previous) version with another label.
Create two views and compare the views with the tool of your choice.
Related
So I just started using Neovim/Spacevim, and it's so awesome!
I am still getting used to everything, since I have never used Vim or anything like that before.
My question revolves around searching for particular text in all the files of the currently open project.
I am using the nerdtree file manager, and I was wondering how I might search through all the files in the project for a specific string. Like if I wanted to search function thisExactFunction() throughout the currently open folder/directory, how would I go about doing that? The main goal is to have a list of all the files that contain this search string.
I have fzf installed (as well as ripgrep), but seem to be having trouble in searching for specific text inside of all files. I can only search for files themselves, or some other search that does not yield what I need.
Can anyone point me in the right direction...? Thanks!
Check out the Ggrep command that Fzf supplies - see this series of vim screencasts to see how to use vim's in built features (quickfix list populated by :vimgrep) to achieve the same using other grepping tools.
Custom functions
I have a function in my .vimrc that uses ag silver
searcher to search within all
the files in a directory (and any subdirectories). So if you install ag, this
should work:
" Ag: Start ag in the specified directory e.g. :Ag ~/foo
function! s:ag_in(bang, ...)
if !isdirectory(a:1)
throw 'not a valid directory: ' .. a:1
endif
" Press `?' to enable preview window.
call fzf#vim#ag(join(a:000[1:], ' '),
\ fzf#vim#with_preview({'dir': a:1}, 'right:50%', '?'), a:bang)
endfunction
" Ag call a modified version of Ag where first arg is directory to search
command! -bang -nargs=+ -complete=dir Ag call s:ag_in(<bang>0, <f-args>)
Bonus
Sometimes it's hard to find things in vim's help, so I also have a function
that uses the one above to interactively search the help docs. This can be nice
to hone in on the topic you want. Use :H for this function (as opposed to the
classic :h)
function! Help_AG()
let orig_file = expand(#%)
let v1 = v:version[0]
let v2 = v:version[2]
" search in the help docs with ag-silver-search and fzf and open file
execute "normal! :Ag /usr/share/vim/vim".v1.v2."/doc/\<CR>"
" if we opened a help doc
if orig_file != expand(#%)
set nomodifiable
" for some reason not all the tags work unless I open the 'real' help
" so get whichever help was found and open it through Ag
let help_doc=expand("%:t")
" open and close that help doc - now the tags will work
execute "normal! :tab :help " help_doc "\<CR>:q\<CR>"
endif
endfunction
" get some help
command! H :call Help_AG()
In my huge project, I would like to count the ".ts" file(s) existence. as well ".spec.ts" files. how to I count them separately. is there a way in "visual studio code" for it? simply counting the file by it's extension.
at present I am trying with "ctl + shif+ f" but not works.
thanks in advance.
Ctl-Shift-F is a good enough approach, if the total amount of files that you will potentially match is less than 10000. This is due to a limitation in vscode, that limits the total amount of matches to this number. Thanks to #Timothy G for pointing this out!
I would do it like this:
To count all .spec.ts files change the search pattern to regex and search for (.*\n?)* (this matches the whole content of the file, forcing a multi-line match in vscode).
Under "files to include" add *.spec.ts:
To count all *.ts files without the *.spec.ts files you set "files to include" to *.ts and "files to exclude" to *.spec.ts:
What about using the file system in your OS ?
In Windows you could search for *.ts and you could see the amount of elements in the bottom left corner of the window.
On linux you could use ls --file-type *.ts | wc --lines
At my new job I'm using Emacs 24 on Windows, and its chief use for me in these particular circumstances is as a file manager.
I'd like to jettison everything from the Dired display except filename, size, and date. This question showed me how to use ls-lisp-verbosity to remove most of the detail that I don't want.
But I haven't found a way to keep from displaying the permissions. I've checked the documentation for ls and for dir, and there doesn't seem to be a flag for "don't show permissions". And so far I haven't found anything in Dired that will omit the permissions. Can this be done?
Your best option is to change the ls switches so that Dired does not list those fields. See M-x man ls for your particular platform, to see what ls switches are available to you.
dired-details.el (and dired-details+.el) are no longer needed if you have Emacs 24.4 (or a pre-release development snapshot). Just use ( to toggle between showing and hiding details.
And in that case you at least have two options to control whether symbolic-link targets or all lines except header and file lines are considered details to hide: dired-hide-details-hide-symlink-targets and
dired-hide-details-hide-information-lines.
If changing ls switches does not help in your case, then you would need to tweak function dired-details-make-current-line-overlay from dired-details.el. The details to be hidden are determined by the first cond clause, which is this (wrapped in ignore-errors):
(dired-move-to-filename t)
That moves point to the beginning of the file name. The next line is this:
(make-overlay (+ 2 bol) (point))
That creates the invisibility overlay from the beginning of the line (bol here) up to the beginning of the file name (point).
If you want something different then you need to get the limits that you want for the overlay. For example, if you want invisibility to start at the file size, then you would search forward with a regexp that finds the beginning of the file size.
You can come up with such a regexp by working from the regexp for dired-move-to-filename-regexp (in library dired.el). It is a very complex regexp that matches everything up to the file name. But you can use it to find the date+time portion, which is either the 7th matching regexp subgroup or the 2nd, depending on whether the date+time is expressed using a locale (western or eastern) or using ISO representation.
You can see how this is handled in the code defining variable diredp-font-lock-keywords-1 of library dired+.el.
But again, the best approach, if it does what you want, is to try to use ls switches to control which fields are listed in the first place. You can easily experiment with switches by using a prefix argument with C-x d - you are prompted for the switches to use.
element * CHECKEDOUT
element /test_ari/karthik/... ... /karthik_omna/LATEST
element /test_ari/karthik/... /main/2 -mkbranch karthik_omna
element * /main/LATEST
I have written the above code and it worked so right.I am so happy for that.But i want to clear somethings from u guys. What does that 3 dots mean in this syntax
/test_ari/karthik/...
and the other 3 dots means
... /karthik_omna/LATEST
And last question but it got great importance. Why should we always use * CHECKEDOUT in the beginning? what happens if we dont use it?
/test_ari/karthik/...
It means that the selection rule which follows (i.e .../karthik_omna/LATEST) will apply to the karthik directory, and to all the subdirectories and files, recursively.
If the selection path had been /test_ari/karthik/* (star instead of three dots), the selection rule would have applied to the subdirectories and files, but not to the karthik directory itself
.../karthik_omna/LATEST
This is a selection rule instructing ClearCase to select the LATEST version of the branch karthik_omna, without worrying on top of what other branch karthik_omna has been created.
If the selection rule had been (for example) /main/karthik_omna/LATEST, it would have selected the LATEST version of that branch only if said branch was created on top of 'main'.
Contrary to the previous '...', there is no '*' for a selection rule.
(*/karthik_omna/LATEST doesn't exist)
As I explained in "How to create a branch", selection rules are read in order and the first one that fits make ClearCase apply it (and ignore the others) for a particular file or directory.
This is why you will always find:
element * CHECKEDOUT
as the first rule, because when you notify ClearCase of your intention to modify that file, it (the file) acquires a special version called CHECKEDOUT which needs to be selected in order for you to be able to modify and then check-in that file.
If that rule was too far down below, ClearCase might select another version, and you wouldn't be able to check-in anything since that file would not be considered checked-out in your view.
I have two different directories and i am making a script which identify that if different directories have the same file name with different changes.i am trying with winmerge commaline option as below ..
WinMergeU C:\Folder\File.txt C:\Folder2
and i also want to merge the all changes into the one file.
Please suggest me on this.
thanks
When I compare folders with WinMerge, I go to File->Open, select folders and check the 'Include subfolders' check-box. Then in the View menu I switch on the Tree View and switch off Show Identical Items.
Here is the manual from Winmerge explaining on comparing two different folders -
http://winmerge.org/docs/manual/CompareDirs.html
The answer from Stanislav works well from the user interface.
From the command line (documentation), you need the flag /r to do the comparison recursively:
WinMergeU /r Folder1 Folder2
Then, as mentioned in Stanislav's post, you can go to the View Menu and Check the "Tree Mode" and uncheck "Show Identical Items" to get a clearer view of the differences.