I've got an Open Source project tracked with Hg. A collegue did some modification without using any version control, and my version also was modified. Now I want to merge the modification he did ( without any version control ) into my trunk, what's the best operation cycle in this case ?
Thank all,
Ask him to make a general patch using diff tool and apply it with patch on your side.
To have this process passed smoother you'd probably update back to the revision your colleague has and then merge 2 heads.
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 forked a project from the internet, and I want to write some new features. I want to write several orthogonal features at the same time, (eg. debug helpers, new feature X, new feature Y), and have the code for all of them in my current directory, but when I commit, I want to be able to say "these files go to branch 'debug'", "those files go to branch 'feature X'", etc. Where these are branches in the 'hg branches' sense.
The reason for this is the project upstream may not want to merge my debug helpers or hacked bug fixes, but I certainly want to use them whilst developing my features.
Effectively, I just want to apply the changes in those files to the branch, but keep several branches checked out & merged to my current working directory.
Is this possible? Perhaps there's some hg extension to do this?
Thanks!
Look at mercurial queues (MQ) for things like debug helpers or local hacks. Very useful for patches that you only want locally and may want to apply to any revision/branch.
Doing the same thing with branches becomes tedious IMHO as you have to be very careful to do the changes for debug and features on different branches, and then merge them in to a local, throwaway branch in order to run anything. You can end up with lots of changesets on the feature branch that leave the tree in a broken state because you can only test after you commit.
I don't fully understand why you'd you would want to do things that way. If your features are orthogonal, you can work on them independently until they are ready to be merged. That is exactly what branches are for after all!
But to answer your question: you could commit on a branch and then, as a matter of workflow, always up to default and merge it in. That would keep the default branch as the sum of the other features. You would need to update to the feature branch before you commit, though and that could get tedious.
The other option for post-facto determining which branch you want to commit to is to use the rebase extension. In this case, you'd commit your changes and then do hg rebase -d targetBranch.
I don't recommend using history revisions as part of your standard workflow, though. That smells to me.
I'm still very new to Mercurial so please let me know what I'm doing wrong.
We have an hg repo for each of our developers. I'm working on a new feature in branch x. Since then, others have made critical changes to the project, which I have pulled into my repo. However, when I'm working on branch x my working copy still has the old stuff, which causes it to not play well w/ our shared MySQL database.
Q: How do I update my branch to have the other developers new stuff while keeping my own code in the x branch; I'm not ready for them to have it yet and I definitely don't want to merge x into default... I'm not sure what to do here...
Or am I going about this the entirely wrong way? If so, what should I be doing instead?
[edit]
Also, I'm using TortoiseHG, so if you have any instructions specific for that it would be appreciated.
[/edit]
You are doing everything right. In order to "keep up" with the work of the other developers, you have to merge the default branch into your x branch. Not the other way around.
When you are in your x branch, it is as easy as doing hg merge default.
Edit : I deleted my statement about hg merge being equivalent to hg merge default, which is false. I misread the documentation.
I have some changed files I don't want to commit (e.g. web.config). Before I pull and update to new changesets, I have to shelve them. After the pull & update, I have to unshelve them.
I'm currently using TortoiseHG. Is there any extension which can do this automatically?
I'd suggest something else: instead of always shelving and unshelving, you could use two different config files: one which is part of the repository and contains dummy/example data, and another one which each user really uses locally, which is ignored by Mercurial.
Check out this answer for a more detailed explanation what I mean.
The example I'm giving there is for Visual Studio, and I see from your other questions and answers that you're apparently using .net and Visual Studio, so you can just use my example exactly as written.
In Mercurial, just hg pull -u. Uncommitted changes are merged with the tip. Same result as shelve, pull/update, unshelve. With TortoiseHg a dialog will come up prompting for discard/shelve/merge.
You may get a merge dialog this way but that would be true with the shelving approach because unshelve may have to merge as well. From the command line you won't get a prompt if there are no conflicts. TortoiseHg may have an option to suppress the dialog if there are no conflicts, but I haven't checked.
I would try a few different things with this.
Regarding the Web.config file in particular, you might want to look at using local configuration files for overrides instead of leaving local changes uncommitted. (e.g. referencing an separate file that is in .hgignore). Projects I've worked on in the past did this to separate test/prod configurations from the settings for development, or vice-versa.
I don't think there is any extension which will do this for you, but you might be better off writing a quick batch or powershell script to do this workflow for you. On previous projects, I had a script which would do something similar in that it would do a pull/update/rebase to keep my changes at the tip (I was working with hg against an SVN server which made that important.)
I know I didn't answer your question directly, but I hope this helps!
Direct answer: https://pypi.org/project/hg-autoshelve/
But a dedicated repository for configuration files seems a better idea as suggested by
Christian Specht there
I have a local mercurial repository with some site-specific changes in it. What I would like to do is set a couple files to be un-commitable so that they aren't automatically committed when I do an hg commit with no arguments.
Right now, I'm doing complicated things with mq and guards to achieve this, pushing and popping and selecting guards to prevent my changes (which are checked into an mq patch) from getting committed.
Is there an easier way to do this? I'm sick of reading the help for all the mq commands every time I want to commit a change that doesn't include my site-specific changes.
I would put those files in .hgignore and commit a "sample" form of those files so that they could be easily recreated for a new site when someone checks out your code.
I know that bazaar has shelve and unshelve commands to push and pop changes you don't want included in a commit. I think it's pretty likely that Mercurial has similar commands.
I'm curious why you can't have another repo checked out with those specific changes, and then transplant/pull/patch to it when you need to update stuff. Then you'd be primarily working from the original repo, and it's not like you'd be wasting space since hg uses links. I commonly have two+ versions checked out so I can work on a number of updates then merge them together.