So here is an example folder hierarchy:
c:\MyProject
c:\MyProject\Folder1
c:\Myproject\Folder2
In SVN, If I am only interested in looking at the history of changes in c:\MyProject\Folder1 I could just navigate to that folder, right click and view log.
With Mercurial doing the same thing shows all the changes in the entire MyProject. Is there a way to filter out and show me only changes in Folder1 (And its sub-folders) ?
It pretty much works as you would expect, same as for svn log:
hg log c:\MyProject\Folder1
In TortoiseHG, you right-click on Folder1 and open the Repository Explorer from there.
This automatically sets the filter in the Repository Explorer to show only the history of this folder.
Something similar is described here (for single files instead of folders, but you get the idea...)
In the new style tortoise hg (Hg Workbench) you can achieve this by right clicking and selecting TortoiseHg => Revision History on a folder in your repo.
What this actually does is filter (ctrl+s) like this file('path:some/relative/path')
Old question, but: if you installed only TortoiseHg with no explorer extensions, then you can press Ctrl-S in it and enter the revision query file("path:SOME/PATH").
Related
I'm new to Mercurial and MercurialEclipse, and I think I'm not quite understanding this:
After I pull from the central repository (with Update After Pull selected), it is my understanding that all files are loaded form the central repo to my local repo. However, after I pull, I'm seeing the following:
Doesn't the star icon indicate that there are differences between my local copy and the central copy?
What am I missing here? How do I make sure that my files are the most recent copies?
Try right-clicking on your Eclipse project and select Team --> Refresh Status. I often have to do that for the status icons to be updated.
Edit: if you want to override all local changes, select the checkbox "Clean update (override local changes)" in the Pull dialog of Eclipse.
When you update it merges the local changes you have with the changes in the revision you are updating to. In the update dialog if you select the "force" checkbox it will revert any uncommitted changes. Other ways to remove your local changes are updating by right clicking on a revision in the history view and selecting "switch to", or use the "revert" dialog.
I added CKEditor to my project. After final configuration, I am not able to commit folder dialog in folder ckeditor/plugins. When I open TortoiseHG Workbench, there is no dialog folder to commit. Other users after update didn't get that folder, so editor not work for others.
I am not ignoring that folder. Here is my .hgignore file:
syntax=regex
^\.
^target/
^jsTestDriver\.conf$
^node_modules/
^run-ft\.bat$
^run-ut\.bat$
log$
versionsBackup$
main\.css$
\.idea$
\.iml$
When I rename folder dialog to something else (for example dialog2), it automatically appears and I can commit, but dialog2 is useless for me. Please, any ideas?
Yes, it is normal, you have
log$
Which excludes the string if it ends with log, as in dialog...
If you need to exclude .log file, use
\.log$
Use hg add in console and add directory by hand (or move .hgignore temporary out of repository and add in GUI)
Try something like hg add -I ckeditor/plugins/dialog/* -n (and fix probably bad pattern for good result)
We use tortoise hg with Kiln. In my vs 2010 c# project there are some files that are part of the repository but I would like tortoise hg to ignore them when I make a commit.
For eg., say in a login screen I may hard code the userid, password for testing. I dont really want this file considered during a commit. I understand .hgignore file but this really works for files that are not part of the repo. Any trick in tortoise hg to ignore files that are part of the repo ? (so they do not show up as modified (M) during a commit.) thanks
I always use a combination of .hgignore and BeforeBuild (in the .csproj file) for things like this.
In one of my pet projects, I have the following setup:
App.config contains my real hardcoded user id and password for testing.
App.config.example is identical, but with fake data like "dummy_user" and "dummy_pw".
App.config is not part of the repository, and it's ignored (in .hgignore).
App.config.example is part of the repository.
Then, I have the following in the BeforeBuild target in the .csproj file of my solution:
<Target Name="BeforeBuild">
<Copy
Condition="!Exists('App.config')"
SourceFiles="App.config.example"
DestinationFiles="App.config"/>
</Target>
All this together has the following effect:
the config file with the real data can never be accidentally committed to the repository, because it's ignored
the repository only contains the config file with the example data
if someone else clones the repository to his machine, he won't have the "real" config file...but if it's missing, it will be automatically created before the first build by Visual Studio / MSBuild by simply copying the .example file (and then he can just put his real login data into the newly created App.config file).
if an App.config with real hardcoded user data already exists, it won't be overwritten when building because the BeforeBuild event will only happen if App.config does not already exist
The answer by Christian is the right one, but I want to mention that TortoiseHg supports what you want with their Auto Exclude List.
One problem with an exclude list is that it cannot work with merges: you must commit all files when you merge and so you'll have to do a little dance with shelve, merge, commit, and unshelve.
When you do a TortoiseHG commit, there is a list of files with checkboxes by them. Deselect the files you do not want comitted.
Or, on the command line, do a commit of the form hg commit --exclude "pattern", where pattern is defined in the hg man page.
You could always use hg forget.
I'd like to know the best/easiest way to get a visual diff of a file given two revisions in Mercurial. I.e., I'd like to visualize the difference between revision 3 and revision 12, etc.
If by 'visual' you mean a text comparison you can do:
hg diff -r 3 -r 12
If you want a GUI tools you can easily configure and use the ExtDiff extension, which comes with Mercurial, and use:
hg yourdiff -r 3 -r 12
where yourdiff was configured in your hgrc file.
In the 'better late than never' category, and in answer to epalm's comment, here is how to compare any two revisions of a file from within TortoiseHG.
From any view that displays the file of interest, right click on the file and select 'File History'. This will open a new window that only displays check-ins for that file. (If the file you want is not visible in the current change set, remember that all files are visible in the Manifest view.)
From the File History window, select the two revisions that you want to compare by doing a CTRL - Left Click on each one. Make sure exactly two revisions are selected or you won't see the context menu you need in the next step.
Right click on one of the selected file and choose the "Diff selected file revisions..." option. A file diff window will open with whatever diff tool TortoiseHG is configured to use.
Note that this answer was written based on TortoiseHG version 2.6.2
I'm using perforce for versioning control. Let's say I am working on a file in the main branch:
//main/xx.cs (it's open for edit)
In the mean time, //main gets branched to //v1 and then //main gets locked.
Is there a way I can integrate my local changes in //main/xx.cs directly to //v1/xx.cs ?
There's a similar question: Can I integrate checked out files into a different branch on perforce
One of the answers there gives:
http://kb.perforce.com/UserTasks/CodelinesAndBranching/BranchingWorkInProgress
which looks like it will provide more than you need.
There is also various p4shelve, p4tar options that might help:
P4 Shelve Python addition for any version of Perforce
P4tar offline (or at least off-server) saving of changes
p4 shelve 2009.2 and later Perforce feature to provide built-in shelving.
Here's one possibility...
Sync //main to the changelist where the branch was made. Resolve conflicts.
Important! Sync //v1 to the same changelist.
Open //v1/xx.cs for edit.
The ugly part: manually copy the local copy of //main/xx.cs over the local copy of //v1/xx.cs
Sync //v1 to head and resolve conflicts.
Submit changes.
Voila!