Quick question on Mercurial. Suppose my colleague and I both have an up to date copy of trunk. We both make changes, then we both push/pull the changes from each other.
I am guessing Mercurial keeps the changes in order based on the date of the commit (since there is no incrementing revision, just a GUID). So what happens if my computer's date is one day behind and I commit half a day after my colleague. Would my change show up half a day before my colleague's?
#Martijn has your correct answer, but it doesn't seem to be clicking. If this makes anything clear pick his:
The commit times on Mercurial changesets have absolutely nothing to do with how they're merged, interleaved, or combined
Mercurial, and other DVCs, do all history tracking based entirely on the DAG (Directed Acyclic Graph), which means:
the only piece of metadata that matters is the parent or parents of a changeset
Before you commit you can see what the parent of your changeset is going to be by typing hg parents and once you commit you can see it in the hg log.
In your examples if you've pulled your colleague's changesets and updated your working directory to reflect them (hg pull ; hg update) then his or her changeset will be the parent of your changeset. If you haven't pulled/updated to reflect his or her changeset then both of your changesets will have the same parent -- they'll be siblings -- when when they're merged neither will take precedence over the other in any way.
The ordering when you do a hg log is determined by the order in which the changeset arrived in your local repository, and can differ from repo to repo depending on where they've pulled from first -- that's why you can't use the integer numbers shown next to changesets for cross-repo operations -- only the hash is global.
In short the date is never consulted in normal operations and is purely metadata with no more relevance than the author or commit description.
Indeed, your changesets are timestamped (internally stored as seconds-since-the-UNIX-epoch and a timezone offset), and when displaying changeset, they are ordered by timestamp and your changesets will be displayed in the incorrect place as their timestamps are be incorrect. See https://www.mercurial-scm.org/wiki/ChangeSet
This is not really that much of a problem though; timestamps have no bearing on how your changes are merged with those of your colleague. Only the changeset IDs matter here and when merging a common ancestor is used. It'll follow the graph of your changesets down looking for a changeset ID that your colleague also has and then merges your and his changes from the on forward. See https://www.mercurial-scm.org/wiki/Merge
So, merges are not affected, only the display of changesets, where your changesets will be sorted into the wrong location. It'll confuse you and your colleague, but your changes themselves are safe.
The order of changesets is not affected by the timestamp in the changesets. The order is determined solely by the order in which the changesets were created in your local repository.
Mercurial has an append-only architecture so when you pull from another repository, the changesets you pull in are placed after your own changesets, regardless of the timestamps in the new changesets.
The revision numbers (the local integer counter) is just a counter: each new changeset gets the next available revision number. The simple range operator in Mercurial works directly on revisions numbers, and so X:Y means "give me changesets with revision numbers from X to Y (inclusive)". This is not so useful when the revision numbers are based only on the order in which changesets were created or pulled into a repository.
Use X::Y instead, that gives you changesets that are descendants of X and ancestors of Y, i.e., it follows the branches in the history.
Related
Suppose I have a revision "6443" however this revision does not have changes which were committed with revision number "6409".
Here to get the changes from "6409" merged with revision "6443" I am thinking of a solution one is get the files from "6409" merge with "6443" and Commit however it would go with new revision number i.e 6444 which I dont want.
Please note here i am trying to merge in the same branch
Is there any other way where I can achieve the same?
Thanks
The DAG you attached shows that a merge is not necessary, as changeset 6409 is a direct descendent of your tip changeset 6443. Thus if the changes of 6409 are not present anymore, there is some intermediate changeset which undoes what 6409 introduced. The right course of action would be to revert or backout that commit which damages the desired changes of changeset 6409.
See also http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html
This question also basically is a duplicate of
How to force a merge with an ancestor?
I'm new to Mercurial and trying to understand how things work.
I wonder what is the difference between changesets and revisions ?
Thanks.
None.
From the Understanding Mercurial page:
When you commit, the state of the working directory relative to its
parents is recorded as a new changeset (also called a new
"revision")...
and further down the page:
Mercurial groups related changes to multiple files into single atomic
changesets, which are revisions of the whole project.
(emphasis mine)
Even if old, someone might stumble on this and I would say that there's a crucial difference. They are related as #Edward pointed out. Still, based on Mercurial's FAQ they are not the same.
A revision number is a simple decimal number that corresponds with the ordering of commits in the local repository.
The important part is local repository and further:
It is important to understand that this ordering can change from machine to machine due to Mercurial's distributed, decentralized architecture. This is where changeset IDs come in. A changeset ID is a 160-bit identifier that uniquely describes a changeset and its position in the change history, regardless of which machine it's on.
You should always use some form of changeset ID rather than the local revision number when discussing revisions with other Mercurial users as they may have different revision numbering on their system.
From experience I can tell, revision numbers do differ sometimes and are not unique.
We recently switched from svn to mercurial. We're using Aptana as our IDE with the MercurialEclipse plugin, along with BitBucket for our repositories and SourceTree as our (additional) source control GUI.
I created 2 new files in Aptana, and committed each of them. Now in the Synchronize view, where the 2 files are listed as "outgoing", I'd like to push only one of them. I avoided using the "push all" icon at the top which would push all outgoing changes - instead I right-clicked a specific file in the outgoing list and chose "push" from the context menu. However, this caused both outgoing changes to be pushed. I can't seem to find any option to push only a specific file or subset of files of the committed changes. Is there any way to accomplish this in Aptana?
Note: My answer doesn't relate to Aptana, but instead covers what I think your issue is.
I think the main problem is a misunderstanding of how Mercurial stores its changes, which coming from a Subversion background is perfectly reasonable.
In Subversion, change history can be considered to be stored per file. That is, if you change two files and commit them, you can easily, and often do, have a situation where files in your working copy are at different versions.
In Mercurial, change history is stored across the whole repository. Committing will create a new "Changeset", which stores the state of the entire repository at that time. When you decide to push a change out to another repository, all modifications (or adds, or deletes, or...) will be pushed out with that change.
A caveat is that when you decide to commit a new changeset to your repository, you can selectively include or exclude files. Files not included will remain in your working copy as pending modifications, which can be committed in a new changeset.
I hope that makes sense to you - if you already understand it, it's a logical concept, but I find it tricky to explain.
So, on to your problem.
Lets say you have two files in your repository, file1 and file2 (it's that or foo and bar). You've changed them both, but they relate to different issues - they can be committed as different changesets:
$ hg log
changeset 0:....
summary: First commit
$ hg st
M file1
M file2
$ hg commit -I file1 -m "Changed file1"
$ hg log
changeset 1:....
summary: Changed file1
changeset 0:....
summary: First commit
$ hg st
M file2
Here you can see that we've committed only one file into the repository, and it's made a new changeset with the complete state of the repository at that time, minus the changes to file2. We can now do the same, committing file2, which will create another changeset. The problem with this approach is that changesets are ordered according to their parent, and so you couldn't easily push just the change to file2, without also pushing its parent - but it may be closer to what you're after.
TL;DR : SVN stores the state of individual files, Mercurial stores the state of the repository as a whole.
I very much recommend reading Mercurial: The Definitive Guide. It's a little out-of-date in places, but I think it will do a much better job of getting the concept across.
In CVS I have a branch (b) off another branch (a) which is off the trunk/head.
Some bug fixes were made in branch (a) that I'd like to go ahead and use in branch (b). How can I pull those fixes into my branch in Eclipse?
head
|
v
a (with bug fixes)
|
v
b (needs bug fixes)
Ideally what you need is to have two tags on a for every feature you want to merge, and then merge the difference between those two tags into b. However, you would also need to remember which ones you have already merged, because CVS doesn't remember that.
When I was working in a company that used CVS and branches, our policy was that bugfixes from branches (a in this case) that ought to be used by other branches need to get merged into the trunk first, and all the other branches merge them from there.
However, it was still very painful if you wanted to cherry-pick individual bugfixes. Essentially, you'd have to remember every fix you've merged (by two tags, marking the beginning and the end of the changes making up that fix).
Generally, in CVS it's much better to remember (in a tag) up to which revision you have merged, and merge everything from there to the head (and then move the tag to the head). In CVS, cherry-picking is painful and requires you to store the merge history somewhere.
When SVN with merge tracking works, it's really nice, I love it. But it keeps getting twisted up. We are using TortoiseSVN. We continuously get the following message:
Error: Reintegrate can only be used if revisions 1234 through 2345 were previously merged from /Trunk to the reintegrate source, but this is not the case
For reference, this is the method we are using:
Create a Branch
Develop in the branch
Occasionally Merge a range of revisions from the Trunk to the Branch
When branch is stable, Reintegrate a branch from the branch to the trunk
Delete the branch
I Merge a range of revisions from the trunk to the branch (leaving the range blank, so it should be all revisions) just prior to the reintegrate operation, so the branch should be properly synced with the trunk.
Right now, the Trunk has multiple SVN merge tracking properties associated with it. Should it? Or should a Reintegrate not add any merge tracking info?
Is there something wrong with our process? This is making SVN unusable - 1 out of every 3 reintegrates forces me to dive in and hack at the merge tracking info.
This problem sometimes happens when a parial merge has been done from trunk to branch in the past. A partial merge is when you perform a merge on the whole tree but only commit part of it. This will give you files in your tree that have mergeinfo data that is out of sync with the rest of the tree.
The --reintegrate error message above should list the files that svn is having a problem with (at least it does in svn 1.6).
You can either:
Merge the problem files manually from trunk to branch, using the range from the error message. Note: you must subtract 1 from the start of the range, so the command you'd run would be:
cd <directory of problem file in branch working copy>
svn merge -r1233:2345 <url of file in trunk>
svn commit
or
If you're certain that the contents of the files in your branch are correct and you just want to mark the files as merged, you could use the --record-only flag to svn merge:
cd <directory of problem file in branch working copy>
svn merge --record-only -r1233:2345 <url of file in trunk>
svn commit
(I think you can use --record-only on the entire tree, but I haven't tried it and you'd have to be absolutely sure that there are no real merges that need to come from trunk)
Bunny hopping might be the solution.
Basically, instead of continuously merging trunk changes into a single branch (branches/foo, let's call it), when you want to pull those changes from trunk:
Copy trunk to a new branch (branches/foo2).
Merge in the changes from the old branch (merge branches/foo into branches/foo2).
Delete the old branch (delete branches/foo).
Your problem is that you're trying to use Reintegrate merge on a branch that has been 'corrupted' by having a 'half merge' already done on it. My advice is to ignore reintegrate and stick to plain on revision merging if this is your workflow.
However, the big reason you get errors is because SVN is performing some checks for you. In this case, if the merge has extra mergeinfo from individual files in there, then svn will throw a wobbly and prevent you from merging - mainly because this case can product errors that you might not notice. This is called a subtree merge in svn reintegrate terminology (read the Reintegrate to the Rescue section, particularly the controversial reintegrate check at the end).
You can stop recording mergeinfo when you perform your intermediary merges, or just leave the branch alone until its ready - then the merge will pick up changes made to trunk. I think you can also byass this check by only ever merging the entire trunk to branch, not individual files thus keeping mergeinfo safe for the final reintegrate at the end.
EDIT:
#randomusername: I think (never looked too closely) at moving is that it falls into the 'partial merge' trap. One cool feature of SVN is that you can do a sparse checkout - only get a partial copy of a tree. When you merge a partial tree in, SVN cannot say that the entire thing was merged as it obviously wasn't, so it records the mergeinfo slightly differently. This doesn't help with reintegrate as the reintegrate has to merge everything back to the trunk, and now it finds that some bits were modified without being merged, so it complains. A move appears kind of the same thing - a piece of the branched tree now appears differently in the mergeinfo than it expects. I would not bother with reintegrate, and stick with the normal revision range merge. Its a nice idea, but it trying to be too many things to too many users in too many different circumstances.
The full story for mergeinfo is here.
I suspect you're not following the merge instructions correctly:
"Now, use svn merge with the --reintegrate option to replicate your branch changes back into the trunk. You'll need a working copy of /trunk. You can get one by doing an svn checkout, dredging up an old trunk working copy from somewhere on your disk, or using svn switch (see the section called “Traversing Branches”). Your trunk working copy cannot have any local edits or contain a mixture of revisions (see the section called “Mixed-revision working copies”). While these are typically best practices for merging anyway, they are required when using the --reintegrate option.
Once you have a clean working copy of the trunk, you're ready to merge your branch back into it:"
I have few problems with merging.