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.
Related
Using TortoiseHg Workbench, almost every time I pull from a remote repository, I have uncommitted code changes so that I need to shelve them before I update and then unshelve them again.
Is there a way to do this all in one click? I seem to remember being able to do this when I used Git (perhaps with GitHub for Windows).
Follow-up or comments
Tried to add button to THG GUI
Defined new tool in Tools menu
Added to toolbar (failed, no buttom on toolbar, I suppose, due to icon size /small/ - using path to big icon file instead of embedded may change visibility result)
Tried to add to Revision Context Menu and use added feature
As you can see - button added, but command failed (for unknown reason): using plain hg for PATH\hg.exe is recommendation from "Define tool" window from THG
So the problem is that all developers need different settings for their local testing, but the settings file is part of the project (unlike the nbproject folder for example that we all ignore). I know about .htignore, but the filter only applies to files that are not part of the project.
If I forget the file, then this removes it from the "global" repository, where we have a "holder" version of the settings file.
Right now we just don't commit that file, but every now and then somebody forgets and pushes his own settings, which then are synced back to other developers and it's a constant pain. We just want to "automatically" not push that file. Is there a solution to this? Are we doing something wrong?
You could add a precommit hook that gives an error every time you try to commit this particular file.
To handle the case of developers that forget to setup such a hook, you can also add a serverside hook that will reject their push.
I'm just playing around with the bitbucket/mercurial pull requests feature, and either something is behaving strangely, or I'm doing something profoundly stupid.
I (theukdave) am the owner of a repository 'RepoA' which was created under a 'team' (which I gather bitbucket doesn't really have anymore). Let's say this lives at bitbucket.org/team1/RepoA
So I created a fork of that repository under my own username and called it RepoB. So now there's a fork that lives at bitbucket.org/theukdave/RepoB
I then create a test commit on a branch off our main development branch 'develop', and then merged that new branch back into develop. I pushed up to bitbucket.org/theukdave/RepoB, and then created a pull request from 'theukdave/RepoB develop' to 'team1/RepoA develop', I add a title and description and NO reviewers (since I'm just testing right now) and click the 'create pull request' button.
A few moments later, the test commit and merge from RepoB is showing up in my RepoA. The pull request is there, I can see it, I have not yet approved it, but the commit and merge and available to all users of RepoA. Even if I decline the pull request, the test commits are still in RepoA.
Is this because I'm the owner of RepoA, and so my pull requests are automatically merged in? Is it because I added no reviewers? A combo of both? Or am I missing something here ...
First of all really interesting. You can resolve this situation using this steps.
To disable automatic branch merging for all repositories in a project (requires project admin permission):
Go to Project settings > Branching model.
Select Disable automatic merging, then click Save.
I hope useful for you.
Simple question: is there a way to revert --all from TortoiseHg workbench? I see how to revert an individual file. Ideally, I could click on a revision, and from the right mouse menu find a "revert all" item.
I'm using TortoiseHg 2.8 on a Ubuntu box.
EDIT I should have provided more details on my question to provide some context. Let me describe the particular use case:
I want to put my working directory back to the state of a past commit so I can generate output from the executable that I know was "good". Once I've generated that output, I want to go back to the tip and continue my development, keeping this history linear. From the command line, I did "hg revert --all --rev 22", generated the output, then "hg revert --all", which did what I wanted. "hg update" will create a history with a branch (if I'm understanding correctly). FWIW there is an "update" button in TortoiseHg (in the box where the list of files is shown) as well as a right-mouse menu item on a given revision.
To set the working directory to match the state of a given changeset (which could be tip), you can use Update:
Right click on the changeset you want to 'revert' to.
Select "Update"
Check the "Discard local changes" checkbox
Click Update
It would be hg update -r changeset -C in the console.
Now you can create the output from the 'state' of the working directory at that point in history (i.e. from the executable at that changeset). If you don't make any commits here there will be no changeset created and therefore nothing is added to the repo history.
Once you have the output to your satisfaction, you can update again to the tip of development via the same process and continue your work:
Right click on the tip of development.
Select "Update"
Check the "Discard local changes" checkbox
Click update
The benefit of using update over revert is that Tortoise will explicitly display the parent of the working directory as the changeset it history. Under revert it could be very easy to revert the files and lose track of which changeset you had reverted to and which part of history you occupied.
(This is assuming that you want to move to that point in the history. If you need to create a changeset that undoes a prior changeset, look into backout, though I'm not sure if that is available in Tortoise.)
You can select all modified files in the list with Ctrl+A and then select "Revert" from context menu.
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!