I want to use Mercurial for a email-based sync system (see this question).
I have played around with sending bundles back and forth ad applying them to the repositories to be synced. But I often get merge conflicts which I have to resolve manually.
But they could be resolved easily automatically: I just want the newer file to replace the older one.
Is it possible to set up a merge-tool in Mercurial that does exactly that: When I hg pull a bundle it updates to the file with the newer time stamp?
When you pull or unbundle new changesets in repository must not intersect with done in parallel (you'll get new head only) - I can't see why you can have merge on pull (uncommited local changes? Commit before pull!)
If your merge-conflicts appear on merge heads (when you merge local head into tip after pull) and you prefer to have tip version of conflicted files and abandon local changes you can use merge with --tool=internal:local option
If you prefer dummy-merge, i.e abandon all local changes from all files, you can use this trick from Mercurial wiki
Related
I have a customized local repository of NopCommerce 3.5. The new version of NopCommerce (3.6) is out and I would like to try to update to it. I downloaded their source code and I would like to somehow replace all the files in my local repository with the new files (outside the repository) and then have mercurial detect the changes and merge them with my changes. Obviously the merge would be manual but I have no problem with that.
In case I am not explaining this properly, let me give you and example:
I have file foo.cs (v3.5) which has custom code in my local repository. I downloaded the new foo.cs (v3.6) which is not in any repository. How can I merge them so that I can keep my changes and the the new changes added by the NopCommerce team?
This is what I have tried so far:
I created a new branch called "Nop3.6" and replaced foo.cs. Then I tried to merge the "Nop3.6" branch with my "default" branch hoping to be able to merge manually and keep both, my custom code and the new changes added in foo.cs (v3.6).
As you might expect this didn't work. my foo.cs file (v3.5) was completely replaced with the new foo.cs and all my changes were lost.
Any help in the right direction would be much appreciated.
Doing the merge vice versa (your changes into v3.6 might work better. Also make sure that you have selected a reasonable merge tool (internal works, but there are possibly more convenient ones out there, I use kdiff3 myself):
I assume you have a repository with v3.5 and on top of that you have one or several changesets which are your own modifications of that source. If you haven't committed your changes as changesets on top of v3.5, then do that now.
Then, in order to get a decent merge with v3.6 do the following:
update to the unmodified v3.5 again. Copy v3.6 over this and commit the complete change as v3.6. You end up with a repository which has two anonymous branches with v3.5 being their common ancestor.
Now you can merge those two branches. As you possibly want to keep your changes on top of v3.6, update to v3.6 and merge your local changes into that branch.
I've just discovered, a surprising for me behavior of cvs.
I change file1 localy
During this time people change other unrelated parts of the same file, and commit to the repository
I update my local copy from repository
At this point I expect my local copy of file1 to contain all changes made by others to this file, unless the update above reported a conflict. However, when I do now diff with head, I discover lot's of differences coming from changes made by others in parts of the file that I did not touch at all.
Any ideas? Is this just the limited abilities of cvs to merge? Any wrong setting? Something in my workflow?
CVS has very limited merge facilities. Switch to a modern system such as Git (perhaps via git-cvsimport if the repo maintainer is uncooperative) if you want a better merge experience. See also Best practices for using git with CVS
The final solution is :
1. Save your local code to another place manually
2. Revert the files which may has conflict to the HEAD (most latest) version on CVS server.
3. Add back your change to the Reverted file.
The concept for above solution is to CLEAR UP all the possible issue by REVERT and get a 100% clean version from repository then add back our changes.
It can resolve below issues which caused by code out of date / code base messed up.
CVS commit had a conflict and has not been modified
CVS update failed
CVS not sync
So i've made the switch from CVS to mercurial for my website.
The biggest issue I am having is that if i'm working on some files that I don't want to commit, I just save them.. I then have other files I want to push to the server, however if someone else has made changes to the repository, and I pull them down.. It asks me to merge or rebase.. either of these options will cause me to lose my local changes that I have not committed.
I've read that I should clone the repository for each project on my local host and merge it into the live when it's ready to do so. This not only seems tedious, but also takes a long time as it's a large repository.
Are there better solutions to this?
I would have hoped that Mercurial would see that I haven't committed my changes (even though I have changed the file from what's on the server) so it'd just overlook the file.
Any input on this would be greatly appreciated. Thank you!
Also, i'm using the hg eclipse plugin to work on my files and push/pull from the server.
hg shelve is your friend here I think.
which comes from the shelve extention (maybe - see below)
from the overview:
The shelve extension provides the
shelve command to lets you choose
which parts of the changes in a
working directory you'd like to set
aside temporarily, at the granularity
of patch hunks. You can later restore
the shelved patch hunks using the
unshelve command.
The shelve extension has been adapted
from Mercurial's RecordExtension.
or maybe its the attic extension
This module deals with a set of
patches in the folder .hg/attic. At
any time you can shelve your current
working copy changes there or unshelve
a patch from the folder.
it seems to have the same syntax as the shelve extension, so I'm not certain which one I've used
I second #Sam's answer. However, if you prefer to use standard Mercurial, a simple workflow is to
save your working dir changes in a temporary file,
sync your working dir with a specific revision, then
push, pull, merge .. whatever you want to do and which requires a clean working copy, and
get back your changes from the temporary file into the working dir.
For instance:
$ hg diff > snapshot.patch # save your uncommited changes
$ hg up -C # get a clean working copy
$ hg pull # do things ..
$ hg merge # .. you need a clean ..
$ hg commit -m "merge" # .. working copy for
$ hg import snapshot.patch # get back your uncommited work
First, are you working from the commandline, or using something like Tortoise?
If you're working from the commandline, and you've done a pull, mercurial will not ask you to do anything, as it merely updates your local repository.
If you then do an hg update and have local changes, it should do what you're used to from CVS. It will update to the tip of the current branch, and attempt to merge your outstanding changes in. There are some caveats to that, so refer to the official docs at http://www.selenic.com/mercurial/hg.1.html#update.
Also, for temporarily storing changes, I would recommend MQ over shelve. Shelve only provides one storage area, whereas MQ provides as many as you need. MQ takes some getting used to, but worth the investment.
The question
An open source program uses CVS for version control. I would like to make a number of bug-fixes and submit patch bombs to the developers with commit access. I would also like to maintain my own semi-private fork that mainly tracks the main code-base but that includes my own features (these features, right now, should not be incorporated into the main code-base.)
I prefer to use mercurial for my own version control needs, but I am open to other version control systems if necessary.
I'd like to:
Be able to easily create patch-bombs against the current CVS source with my own bug-fixes
Keep track of history on my own features
Have fixes and improvements from the main tree easily incorporated in my new-feature fork
Easily apply my own bug-fixes to my new-feature fork
Be able to work and track change history without an Internet connection.
What suggestions do you have for doing this?
My current idea
My own best guess is below, to give you a better idea of what I am thinking about.
I will have 3 mercurial repositories.
The first two repos are managed as specified at (https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS). One just mirrors the latest changes from the CVS upstream. I do "cvs update" then "hg commit" in this repo. The second repo holds my bug-fixes as patches using the mq extension and I pull from the the first repo and re-base my patches every so often. When my patches are incorporated into the main tree, I remove the patches from the patch queue/make them permanent commits.
The third repo is my local fork. It will start out as a clone of the first repo. Then each time I do an update of the first repo, I'll pull from it into repo 3. My own features will be directly present as commits in this repo. When I fix a bug, I'll export a patch from repo 2 and apply it to the appropriate pull from repo 1.
I have used Git to manage changes on top of a CVS repository in a similar way. My solution in Git uses local branches instead of multiple repositories, but it sounds essentially similar to your proposed idea.
I found that this arrangement works best if you commit all the CVS metadata (in the CVS/) subdirectories) to your mirrored repository. This means that the CVS metadata gets replicated in the other repositories, but it doesn't cause any harm (and lets you run commands like cvs diff if you need to).
If a file is committed several times with various changes, how can I fetch one change at a time, i.e., one changeset at a time?
I use eclipse, subversion, and subclipse, and I can't change the former two for the time being (or the MS platform..).
In my Team/Synchronization view in eclipse (using subclipse), choosing the changeset model, a file seems to be listed only in the latest relevant changeset even if all changesets are listed. So an earlier changeset doesn't necessarily show the full set of files in the original commit, nor the original diff for a file in a commit.
Update: I'm thinking about using changesets for simplified code review, so I'd like the partial update represented for all the files commited in one changeset. It's easy to get diffs and specific revisions for specific files in eclipse, but I'd like to step through all the changes in one specific commit/ changeset in a practical manner.
As I'm sure you know, svn up will by default grab the latest revision of the file.
However, you can use the -r parameter to svn up to grab a particular revision of a file. So if you know a file was committed in revisions 5, 7, and 9, you could do this:
svn up -r5 myfile
svn up -r7 myfile
svn up -r9 myfile
I believe (but I don't have an installation of it in front of me) that Subclipse has a similar option, labeled something like "Update to Revision..."
Subversion does not support atomic changesets.
(Note: If anyone can prove me wrong, I'll happily switch accepted answer.)
I've compared Git and Subversion using TortoiseGit and TortoiseSVN (and looked at what is possible on the command line).
With both Svn and Git I can update to a certain revision, or see and update to different versions of only one file at a time.
With both Tortoise clients can I see individual commits (revisions) from the repository and look at changes between a revision and the previous revision. (Note that I can't seem to do this in Eclipse, ref the question.)
Only with Git, however, can I update to or cherry-pick an isolated commit. The closest I've seen to this functionality in Subversion is to update to head and then revert a certain revision with a "subtractive merge"...
Test setup: make a project, check out or clone the project, make 2 separate commits to repository from elsewhere, including at least one file that is modified in both commits.
Then, with Git: fetch remote changes.
Then, with both Git and Subversion: look at the log.