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?
Related
Before committing I export my code changes in mercurial like
hg diff -r tip > d.diff or hg export -o d.diff It creates a nice .diff When I upload this to review board it returns empty diff file.
File is not empty. How can I fix this?
The workflow you are using (manual hg diff + diff file upload via web browser) is painful and lacks flexibility. When an error occurs, reviewboard is not very helpful in explaining what is going on (to use an euphemism :-).
I suggest two different approaches, which often work out of the box. They are in order of preference from my point of view (that is, I prefer option 1 to option 2).
Use the hgreviewboard extension. This allows to stay in hg for all reviewboard operations: hg postreview ... will do the diff and upload to reviewboard. hg help postreview will explain all the options and the advanced usage.
Use the post-review script, provided by reviewboard.org. This approach also allows to avoid the manual steps of the browser upload. The link above has full documentation.
We are looking for a way to add / update a custom tag at the beginning of each file being committed during a commit. Its some kind of local timestamp we need.
I was thinking of hooks.
Unfortunately I cannot find a useful hook for that:
precommit: unsuitable as it fires before hg knows any metadata of the commit
pretxncommit: unsuitable, as the documentation clearly states that we should not change the working dir at this point
commit: unsuitable, as it fires when the commit has already happened.
EDIT:
I can not use hg's inline changeset-hash and / or datetime. For the following reason:
Our files get later imported into an external system (we do not have control over) which does not support any kind of versioning.
To simplify stuff: let's say tag is an ever-incrementing no. (everytime we commit). This tag is then used to help getting an idea of the version / status of the file on the system in respect to the file in the repo - like "no. of changes we're missing" and such.
Any ideas?
I would suggest a two-stage solution. First, create an alias along the following lines:
[alias]
tcommit = !tag-changed-files && $HG commit "$#"
Here, tag-changed-files would retrieve a list of modified and added/moved files via $HG status -ma -n or $HG status -ma -n -0 and tag them. I am assuming that re-tagging files that have been modified but aren't being committed yet is a harmless operation; more on that below. Note that you can even redefine commit if you absolutely want to via:
[alias]
commit = !tag-changed-files && $HG --config alias.commit=commit commit "$#"
However, this is potentially problematic, because it may confuse scripts.
You could also integrate the commit step in the program if you wanted to, and even try and parse the command line arguments to only tag those files that you are committing. For this approach, using hglib might be appropriate to avoid the overhead of invoking Mercurial multiple times. (Note that hglib and other tools that use the command server ignore aliases and command defaults, so this works even if you alias commit).
Second, you'd install a pretxncommit hook that verifies that files that are being committed have indeed been tagged appropriately (to ensure that the tag-changed-files program hasn't been bypassed by accident).
This should work without a problem on full commits; for partial commits, any files that were changed but have not been committed would also have been retagged, but since they will be either committed later (and get tagged properly at that point) or reverted, that should be harmless.
an idea of the version / status of the file on the system in respect to the file in the repo
Just one idea
Stop reinvent the wheel
Incremental counter is just shit, if you task is "to know, which version is on LIVE and which - in Mercurial's tip" (and this is your real business-task, yes?!)
Keyword Extension give you last changes per file.
If you want to inject changeset of repository into files (it's reasonable good way), re-read this part of wiki-page
If you just want to version your entire repo, do not use this
extension but let your build system take care of it. Something along
the lines of
hg -q id > version
before distribution might be well enough if file-wise keyword
expansion in the source is not absolutely required
You can insert hg id output into files at export stage (in planetmaker's sed-style), bu you can also have this additional metadata in files permanently in VCS with special encode|decode filters
There is - to my knowledge - no intrinsic system in mercurial which supports what you describe. However I can recommend an approach which somewhat is adopted from building a software release package from the repository: Make a small export script which replaces a certain KEYWORD in your files with the version information you need. A Makefile target could look like which creates a zip export for revision XXX with version information in all files which support it (thus contain the verbatim KEYWORD - use something truely unique here):
VERSION=$(hg log -rXXX --template="Version: {node|short} from {date|isodate}")
export:
hg archive -rXXX -t files export
for i in $(hg ma -rXXX); do sed -i "s/KEYWORD/$VERSION/g" $i; done
zip -9rq export.zip export
I use a similar approach in my Makefiles where I create versioned export for the source of a particular revision of my software.
EDIT: if your purpose (as stated by the comment) is only to implant the number of commits made to that file: then you can use indeed a pre-commit hook and modify the file. You can count the number of modifications made to a file with hg log FILENAME --template="{node}\n" | wc -l. Do that for every file and do the sed replacement in the header of each file in the pre-commit hook.
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.
When I use ST build system, "built-in output pane" prints various things like expected build output, but also cmd executed, active dir and path variable. Now cmd and dir are just fine, but printing path variable is totally unnecessary for me and it distracts actual output content, as it's just very long string of paths, shadowing all other output.
How can I instruct ST not to print path variable on build?
By adding "quiet": true to the Build System configuration file (JSON), you can prevent all "debug text" from appearing on build failure. This will include:
shell_cmd
cmd
dir
path
To exclude only path, you would need to modify the Packages/Default/exec.py file. Under the ExecCommand class, run method, look for self.debug_text += "[path: " and comment the line out.
To get to this file in ST3, you can use PackageResourceViewer, and type PRV: in the Command Palette to find PackageResourceViewer: Open Resource.
However, note that doing this, will create a file that will override the one that ships with ST3. So it is recommended to delete your override (Preferences -> Browse Packages from the menu, Default folder, exec.py) when a new build of ST comes out, as the official version may change to fix bugs etc. You can then re-apply your changes following the same steps as above, if it is still necessary. (Maybe an option will be added to exclude the path from the output, sometime in the future.)
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.