I'm using cleartool to make baselines in my stream, using
cleartool mkbl -full <baseline-name>
If I have files checked out in my view (in my case, always an oversight), I get the warning
cleartool: Warning: There are checkouts in view "<JXG-view-name>".
But as this is just a warning, cleartool continues with making the baseline.
What I need to do is stop immediately when given this warning.
How can I abort the command automatically when I get this warning? I thought it would be a cleartool command-line option for mkbl, but I couldn't find it in the documentation.
No, there is no native way to look for checked out files on a cleartool mkbl itself.
It will simply labelled any checked-in elements, leaving the current checked-out version untouched.
However, you could try and write a pre-op trigger on mkbl (a bit as in this thread) in order to perform an cleartool lsco -cview and see if there are any files checked out.
cleartool mktrtype -element -all -preop mkbl -nuser ccadmin -exec "..."
You can limit the lsco to a branch (the one named after the Stream) in order to avoid any performance issue.
Related
I'm trying to cross compile GNU grep for Windows from Fedora, using their mingw64 cross compilers. The process is really easy, with one exception. By default, it appears that mingw64 doesn't expand wildcards on the command line, so that grep FOO * gives "Invalid argument: *" rather than searching all files in the current directory.
After a bit of research, I found that there is an external symbol, _dowildcard in the mingw64 CRT, that will trigger wildcard expansion if set to -1. But I've found no useful documentation on how to set this (maybe because it's considered obvious ;-)).
I could modify the source code to set the variable, but I'd much prefer to not have to modify the source if at all possible. (I want to set up an automated build, and applying code patches just adds complexity that I'd like to avoid). Is there any way to set _dowildcard from the configure or make command line? I seem to remember older versions of mingw having a setargv.obj file that could be linked into your project to enable wildcard expansion - is there anything similar for mingw64?
Answer from #ssbssa above:
There is a file CRT_glob.o file supplied with the mingw packages, in /usr/x86_64-w64-mingw32/sys-root/mingw/lib/CRT_glob.o (or the corresponding location for 32-bit) that you can link with your executable to activate command line globbing.
You have to specify the file by full pathname for the linker to find it.
I did the __disable-web-security in Terminal on Mac. Do I need to enable it again? Or does it enable by itself after restart?
If I need to enable it again, how do I do that? I searched everywhere, but didn't find.
Go to chrome://version and look at the Command Line. If the command line argument is still there, you should restart chrome and then launch it normally (without the flag).
A bit more context: "Flag" refers to two slightly different concepts in Chrome:
Any command line argument that starts with a -- (as opposed to an argument that names a URL or a file, for example).
The list of toggles available at chrome://flags.
Any arguments added manually to the command line will only persist until you quit Chrome. On the other hand, the toggles set at chrome://flags will persist until they are reset. (To further blur this, invoking chrome://restart will preserve the command line flags.)
This particular flag makes its presence fairly obvious, with a banner:
You are using an unsupported command-line flag: --disable-web-security. Stability and security will suffer.
So it should hopefully be clear whether the flag is present (and also why this is the sort of flag that can't be persisted at chrome://flags).
The flags set in #2 are delimited in Chrome's command line by the --flags-switches-begin…--flags-switches-end section. Arguments outside of that section are coming from somewhere other than chrome://flags (namely, from the command line, except in the case of Chrome OS and Android, which have their own startup procedures).
I'm trying to write some scripts for doing some simple housekeeping tasks in mercurial and one of the things I frequently need to do is check if the working set is "empty" (depending on context, that could mean untracked files or modified tracked files).
The hg status command exits with exit status 0 unless there was an internal error, in which case it exits with exit status 255.
If a few of my scripts, I'm doing something silly like capturing the output of the hg status command and checking whether it's empty or not.
In other cases I'm checking the exit status of hg id -i | grep -qvF + to check whether there are dirty tracked files.
Both of these seem a little brittle. Are there dedicated subcommands for "querying" the repository to see if there are "untracked files" or "dirty tracked files" or "removed files" or various other interesting things in the working set?
hg status is the command to check for modifications of the working directory with respect to the checked-out revision - thus you are doing the right thing.
You can get away with exclusively using hg status. Using the --mard (or --modified --added --removed --deleted) flags will yield empty if the tracked files didn't change. And using -u or --unknown will show files which are neither ignored nor tracked - and empty output should always indicate no changes to tracked files nor any non-ignored files (but there might be new files which match one of the ignore patterns).
The output format of these commands (at least in the English original, thus LC_ALL=C hg status) is treated by mercurial as API, thus you should be able to rely on it.
Depending on your actual use-case you might want to look at the mercurial command server - but for a script which runs occasionally it might be quite over the top.
test -z "$(hg status -mard --template x)" && echo clean || echo dirty
Seems to work
I have followed the instructions at http://www.semanticmerge.com/sm-guides/main.shtml#HowtoconfigurewithMercurial but they are configured for kdiff3 and I would like to use p4merge to do my textual merging. My current mercurial.ini looks like this:
[merge-tools]
semantic.executable = C:\Users\JP\AppData\Local\PlasticSCM4\semanticmerge\semanticmergetool.exe
semantic.premerge=False
semantic.binary=False
semantic.args=-b=$base -s=$local -d=$other -r=$output -l=csharp -edt="p4merge.exe ""#sourcefile"" ""#destinationfile""" -emt="p4merge.exe -le 'win' -dl ""#basefile"" ""#sourcefile"" ""#destinationfile"" ""#output"""
semantic.gui=True
semantic.checkconflicts=True
With my current configuration when there is a conflict in a file that ends in .cs SemanticMerge runs as expected, but when I use the merge command in SemanticMerge to run a textual merge I get an error alert stating:
Error starting P4Merge
Errors: 'c:\directory\1d37-some-guid.tmp' is (or points to) an invalid file.
Is there in incompatibility or is my above "semantic.args" section configured incorrectly?
UPDATE
I am getting the error when I click the merge button on a specific change. See screenshot below. The answer is right though in that I should just run the text merge using the "run text merge" button.
I´ve just tested the Semantic Merge-Mercurial integration (configuring p4merge as the external test merge tool).
This is my mercurial.ini:
[merge-tools]
semantic.executable = C:/Users/carlos/AppData/Local/PlasticSCM4/semanticmerge/semanticmergetool.exe
semantic.premerge=False
semantic.binary=False
semantic.args=-b=$base -s=$local -d=$other -r=$output -l=csharp -edt="p4merge.exe ""#sourcefile"" ""#destinationfile""" -emt="p4merge.exe -le 'win' -dl ""#basefile"" ""#sourcefile"" ""#destinationfile"" ""#output"""
semantic.gui=True
Semantic. checkconflicts=True
When I perform a Hg merge, the Semantic Merge tool appears, and if I select "run text merge", the text merge tool is working fine. It seems that your issue is in the P4Merge tool installation. Could you try manually launching the P4Merge tool using command line?
I suddenly have a few files that show as modified, but KDiff says they are binary equal. Reverting and discarding those changes does nothing.
Somehow, the eol extension is enabled and when I try to disable it, I can't view that one repo's Working Directory in TortoiseHg. An error appears:
[Error 6] The handle is invalid
When using the command line hg status, this error appears:
'cleverencode:' is not recognized as an internal or external command,
operable program or batch file.
When using hg revert myfile, .orig files are generated but the files still appear as modified and the same error from above appears.
When updating to a previous commit, a whole lot of other files get in the same situation like those few I have now.
If necessary, I can throw away this clone and make a new clone, but it would be nice if this can be resolved without doing so.
Was able to solve it.
My global mercurial.ini had some lines with cleverencode in them. After removing those, the issue has disappeared. Enabling/disabling the eol extension also doesn't seem to cause any issues any more.
I suspect the troublemaker was Atlassian's SourceTree, I had installed an update yesterday and it asked if automatic line ending handling should be enabled. I'm quite sure I unchecked it, regardless, it seems to have mixed eol config with win32text config.
See also: [SRCTREEWIN-708] Possible error with Mercurial line ending handling configuration - Atlassian JIRA
I found that the cleverencode did not work for me -- I didn't have it in my mercurial.ini. My case was also a binary file that mysteriously got marked as modified and would not go away with revert, clean, etc...
I did some poking around and fixed it: there's a repo/.hg/largefiles directory. I believe mercurial keeps this as a local cache of binary files in order to revert back changes. In this directory you'll see a bunch of file names in hex. In TortoiseHg "browse" your binary file causing the problem. It'll show you the hex code corresponding to your binary. Find that file in the largefiles directory and delete it.
You should now be able to revert the file back to unchanged. I think mercurial uses the largefiles version to revert first. Then, when this version doesn't match the repo version it gets marked as modified (in my case my binary somehow got truncated to 0 length) and will never go away.
You can also just delete the largefiles dir altogether if you can't match the hex name. It will get recreated as needed. I think the only repercussion is that it's take longer to do some binary file operations since it will have to go to the server.