I am working with TortoiseHG on a Windows 7 system.
I was working on the default branch, and the R&D team wanted to try out a different algorithm, so I created a new branch using the answer given here, called quadraticTest.
A couple of commits were made to this branch, and the output was found unsuitable.
Now I want to go back and work on the default branch without merging changes from the quadraticTest branch.
Basically, I'm searching for the GUI equivalent of hg update default command
How do I move the Working directory back to the default branch with ToritoiseHG?
If you're looking at the tree, with the graph view, find the revision you want to check out, right-click on it, and select Update...
But let's say that you're having trouble finding the commit -- maybe you have a lot of branches, and so you don't see the revision you want to check out. Turn on the Filter Toolbar (View > Filter Toolbar).
Look on the right. You'll see a dropdown that says something like ★ Show all ★. Click on that to list all your open branches. Select the branch you want to check out, and it will filter the graph view so only commits on that branch show up. Then it'll be easy to find the most recent commit on the default branch, because it'll be the top one.
Related
I'm looking for advice on how best to organize my repository to handle outside changes. And, I have a simple user question on creating a branch in TortoiseHg. This is my first time setting this sort of thing up, so I'm having trouble figuring out the most straightforward way to handle it.
I have a website set up on a service. The theme we're using is based on one of their examples. Occasionally, they'll update the theme we're based on. And, most of the time, I would like to incorporate most of those changes.
The part that is tripping me up is that I don't necessarily want to incorporate all of their changes. So, is the correct way to do it to create two branches? One that is canonical version, straight from them, containing only their edits? And the other is our release branch, that we merge in only portions of their changes?
Will the canonical branch persist? Or, does it come into existence only when they do a new dump, and then I do a manual merge back into my release branch with the changes I want to incorporate?
If it's persistent, is there some way to use TortoiseHg to create the branch back at the root? Or, do I need to dig into the command-line syntax to do that? I know this is a one-time thing for this project. But, I'm looking for advice on how to do this in other software situations, where I want to go back to an earlier version to make a patch. I'm sure there's a tutorial for exactly this situation, but I wasn't able to come up with the correct search phrase to find it. At least, not using TortoiseHg.
If upstream theme is also version-controlled (in any SCM, supported by Mercurial), two long-term branches with grafting some subset of changesets from VENDOR to MY is, naturally, fast and easy way (another possible solution is MQ-patches on top of branch with vanilla theme, but it's slightly harder way)
If original theme not versioned, you can just grab sources from time to time, edit (incorporate own changes, remove unwanted) and commit this own changeset into single-branch repository
is there some way to use TortoiseHg to create the branch back at the root?
I can not recall or find (with quick-search) nice & obvious way to create branch in GUI-way (i.e. big button on toolbar "Branch"), but you can create branch at commit stage (anyway, branch doesn't exist while at least one changeset in this branch isn't committed). In order to create branch, starting from <some old> changeset, you have:
Update to <some old> changeset (RClick - Update...)
Commit (without changing anything), but in commit dialogue use "Branch" button on commit-toolbar (see 1) in order to change old branch-name to some new (see 2)
I've been trying to find actual documentation for Sourcetree without much luck, so I figured I'd ask here. I'm a relative newb when it comes to version control, with my current project being my first effort. I'm using Sourcetree on Windows 7 as a frontend for Mercurial, I've got my development code on my local machine in C:\inetpub, and whenever I do a Commit I then switch Sourcetree over to the cloned repository on my backed up network drive and do a Pull of the changes I just Committed so I've got the development history backed up.
What I'm trying to wrap my head around is using Sourcetree to set up a Debug branch so I can fix bugs on the version of the code running on the production server while simultaneously doing development. Obviously a common need, but I can't grok it. I am expecting there to be two code locations, so I can pause in mid-edit on the Development branch, make changes to Debug, and them come back to my changes in Development and finish them up before merging in the changes to Debug. If that's not how it works that's presumably part of my confusion. Any suggestions on where I can find clarity? Pointers to existing tutorials and the like would be fine, I just haven't been having luck searching Google, and I haven't been able to locate any actual Sourcetree documentation.
NOTE: Based on responses I've seen to other questions I've read about Sourcetree and Mercurial, I'll state upfront I have no interest in discussing outside repository hosting unless somebody can explain why it will help with this problem.
Two things here:
You do not need to change repository to pull, you can also push from your local repository;
You do not need 2 code locations for switching from one branch to the other. It might help, for larger projects, but I suggest you get comfortable with Mercurial before doing so.
So, for number 1, there is a default source or remote repository for every local repo. It is either defined by the user or it is the source repo from where it was cloned. Whether you push or pull, it will default to that same source. You can push/pull to multiple sources as well, but this is not your case at the moment. In the normal workflow, just issue a hg push every time you commit, and your changes will be propagated to the other repo.
For number 2, a Mercurial repo, as you already know, can have multiple branches. When you commit a changeset, it is automatically done on the current branch. In SourceTree, click on the Branch button, and enter a new branch name. The next commit you'll do will be the head (and the start) of your new branch. After that, you can update back and forth between the 2 branches, and your code will change accordingly. That means that you can update at any time to the head of any branch, make some changes, commit, and then jump to another branch, and so on. So no, you do not need multiple repositories.
Normally, the proper practice is to have a default branch (default name is rarely changed!) where you have your current development source. For every issue or feature you are fixing/implementing, create a new branch from the default branch to put your new code. Once that branch has been reviewed and tested, merge it back in the default and close the former.
For your current development, if you need an additional stable and safe trunk, you can create a Production branch, which would be the stable code that will run on your server. Once you are satisfied with the default branch tests, you can then merge it in Production to include your changes up to that point.
As a convention, make sure your server is always running the code from the Production branch, for the more stable code. At least, that is what I understood from your initial question.
We are using mercurial in a single repository. We have a master branch and a develop branch (as well as feature branches, but they aren't germane to the issue at hand).
We tag the master branch with releases (5.1.0.102, etc). We do our development on develop.
But now we want to fix a bug in a previous version. There are a lot of questions here on SO about this issue, but none of them seem to explain what I want to do.
What I want to do is this:
Update to the point where we released (say 6.1.1)
Fix a number of bugs in that release
Label that resulting code state as (6.1.2)
Do a build of this new 6.1.2 codebase.
Migrate those fixes into the develop branch
Do this in such a way that I can go back to 6.1.2 and fix bugs there if need be.
I can't seem to do this via updating. I tried to update to the 6.1.1, create a branch, and go from there, but that brings in the tip of the master branch, including all subsequent changes.
Is there a standard way of doing this? Did I explain that correctly so you guys get what I need to do? It seems like this is a pretty common thing to do.
You don't need to explicitly create a branch. The way I would do it is this:
Update to the point where you released (6.1.1 in the master branch).
Make changes and commit them.
Tag the latest commit in master as 6.1.2.
Pull those changes into the develop branch.
Continue working.
If you need to make more changes, then simply repeat the above but using the 6.1.2 tag in the master branch.
You really shouldn't need to create a named branch unless you truly want to have a full-out branch. What you probably want to do is:
update to 6.1.1
make the edits
commit (will create a new un-named branch)
tag that new revision as 6.1.2.
You can then merge that edit into your develop branch
As long as you are updating to a revision earlier than the tip on the Master branch, the commit will make a new branch off of it.
This will leave the version tagged so you can easily get back to it.
The problem that I'm running into is that I have some code reviews to do, with ~10 commits per review. It's an active repo with constant commits from developers. I have TortoiseHg filtering my changesets so that I am looking only at the ones that I care about.
What I would like to see is the difference between the changeset before the first change, and the last (without all the non-related changesets showing). I simply want to see the final results of all these changes. I don't care that there was some horrible code in changeset 1, that was fixed in 3. I just want to see the diff of what ultimately got merged through all these changesets.
I feel like I'm missing the obvious, and this isn't a bright question. Nevertheless, I'm asking anyways. Anyone?
I'm not sure about 1.1.8, as I'm using the 1.9/2.0 candidate release, but I believe you could left-click on changeset1, right-click on revision3 and select visual Diff. This should open your diff tool of choice and only show you the diffs between the 2 versions.
When I did this in the newer tortoise, it opened BeyondCompare in directory compare mode, with revision1 on one side, and revision2 on the other.
Don't merge in between commits and diff off the developers clone between start and finish changesets.
Or If merges occured, update and merge everything and then take the entire codebase (or just changed files) and dump it onto a clean tip clone (make sure you are working with the same version to avoid overwriting anything). Recommit all at once.
I downloaded TortoiseHg 1.0 for evaluation. For the life of me I can't figure out how to make a branch. It seems to understand branches (e.g. in its repository browser) but I just can't seem to find a way to make a branch. This seems like such a fundamental capability since out of the often touted benefits of DVC is the lightweight branching.
I Googled around and couldn't find much discussion of this topic (at least for recent versions) so I have to assume I'm missing something, right?
Update: So I flagged Chad Birch's answer below to answer the "new branch" issue. As he correctly points out, you do a commit and then click on the branch button to bring up the branch maintenance dialog which is where you create new branches. I kind of wish they had given us a context menu option for this. Once you've branched, the next natural question is how to merge and this is also not obvious. It turns out that option is buried in the repository explorer. You need to select the head of another branch, right-click and then select "Merge with...".
As shown in the docs, all you should need to do is just click on the branch: default button near the top of the commit dialog, and change to a new branch name.
To start new branch with TortoiseHg press Commit... then, above Commit message press Branch, then "Open new named branch: "
Just wanted to add that in order to push new branch to remote repository there is a checkbox on the Synchronize tab under Options of "Allow push of a new branch" - you have to remember to turn it off again right afterwards.
Most of the time in mercurial, you clone the repository to make a branch.
You can then merge the separate repositories once you made your edits and commits.
This might sound like it would take up a lot of disk space but on most operating systems, mercurial will make hardlinks instead of copying the files. Anyway, disk space is normally cheap, and because it's local it's rather fast.
If you think about it, every "checkout" (in svn terminology) or "clone" (in mercurial terminology) is really a branch that will probably be merged back so it makes lots of sense that clones are the common way of making branches.
Before commiting, click on Branch button (see image), Then select a branch or create a new one (by typing where you select the branches).
See the image here