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.
Related
I'm transitioning from using Subversion in Eclipse for code management to GitHub in RStudio. It's starting to make sense, but I can't seem to figure out how to pull effectively.
Specifically, if I use the Pull arrow in RStudio, every file change in the repository automatically updates my local files without warning. I can see how many files were updated, but not what changed!
Here are the questions I'm hoping to get help with:
1) Can I preview the repository file changes in RStudio before I pull them locally? With SVN in Eclipse, there was an indicator showing files with a difference, and the option to view side by side.
2) If multiple files have been changed on the repository, is it possible to pull just 1 locally?
3) How can I revert a local file to a previous version?
Right now I've been trying to do this all within RStudio for simplicity. I haven't used things like the GitHub desktop client.
I appreciate the help!
I would suggest you better get used to the git's own tools to stay informed about your repository.
For example you could do following.
Before you pull, check your current commit logs
git log
This should show you how your current commits stack up. Note the latest commit id (first 4-5 letters would usually do)
Now after pulling you can see the difference using following command
git diff --color your_previous_commit_id..HEAD
If you don't like the changes and want to go back,
you can just reset to your favorite commit with following command. BTW run "git stash save" to keep a copy of your uncommitted changes.
git reset --hard you_favorite_commit_id
Note: that this will delete all your uncommitted changes unless you stashed them and put your local branch behind the remote repo branch you are tracking again.
Wondering where to put these commands? Check https://git-scm.com/downloads.
What's good about using these git tools is that if you switch between IDEs you don't need to search for same functionalities you had in your earlier IDEs.
I am very new with git and repositorys and I have a problem. Me and my collegue were working on the same file.
He commited and pushed his changes.
I commited my changes
I pulled
Now I have conflicts and I want to solve them. How can I overwrite the conflicts so that my changes are on the file? I am working with Eclipse.
There is no easy way to resolve conflicts. But tools are available to make the process a little easier. Anyhow you will have to decide and manually make the changes so that both of your changes are available in the latest file.
Try: git mergetool
If you both edited separate parts of the file then the tool will automatically merge whereas if you both have edited the same part then some manual interaction is needed.
If you want Your changes you can use:
git fetch -p
git merge --ours
This will merge the remote with your local branches and in case of any conflict - use your version of code.
Quite often I have a situation like the following:
some Hg repository with a bunch of configuration files that are shared
some configuration files contain passwords, that should not be shared, they are local to the user
I would like to keep a version history on these files, but they will only occasionally be updated. It is annoying if every time you do a commit or merge or update you have to remember that you do not want to commit your locally changed password.
How can I freeze a file in the repository (and conversely, for the occasional legitimate update, unfreeze it) so that it does not appear in the commit list, but does appear as versioned in the repository and everyone can share a base copy?
This question gets asked a lot, and the answer is always the same: there's no good way to do what you want. A file that's tracked is tracked for all changes.
The setup everyone settles on is committing a configurationfile.example to the repo where changes everyone needs are shared, and add configurationfile to your ignore. If you're savvy you then have your launch script copy configurationfile.example to configuration location if it doesn't already exists. If your configuration format is flexible enough to support an include (most are these days) you have you configurationfile committed and have it do an include of a non-tracked (ignored) configurationfile.local where people override things. This is how everyone does it in both git and Mercurial.
-X option for commit, none (easy) for merge
-X --exclude PATTERN [+] exclude names matching the given patterns
i.e most times you commit hg ci -X FILENAME, sometimes - pure hg ci. You can define hg ci -X FILENAME as new alias and use two different commands for different commits
In case of merges you can try to define for config-file special merge-tool (provably internal:local or internal:fail)
Anyway, you selected wrong and error-prone method of storing local configs as shared common files. (Viable) alternatives may include (in order to name a few)
Config.TEMPLATE in repository and modified for local needs hgignore'd Config
LocalBranch, in which you store code with location-specific changes
MQ extension (somehow related to 1-st solution) - repository stored "vanilla" config, all local-only changes placed in MQ-patch
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
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