I use mercurial on a standalone computer. I have also made some small changes of the source code on this computer. Now I want to update this code with a new version that I can bring to this computer on a CD or usb-stick as a gziped tar file. How do I do this update in the best way, and keep my changes of the standalone source.
Update: I forgot to mention that the files on the USB-stick is not from a mercurial database, they are just a bunch of source-files from a perforce controlled source tree. We have mercurial only on the standalone computer.
On the remote machine (first time):
hg clone {path_to_repository} {path_on_usb_stick}
On subsequent runs:
cd {path_to_repository}
hg push {path_on_usb_stick}
Then on the local machine:
cd {path_to_repository}
hg commit
hg pull {path_on_usb_stick}
hg up
At some point, hg might warn you about multiple heads, which means there are conflicts that you need to resolve by running hg merge.
To get your changes from the local machine to the repo server, you reverse the procedure.
Why not just put Mercurial binaries and a .hg repo right on the flash drive. Then you can push/pull to/from it at home, and copy atop it at work.
Related
I created a mercurial repository on some file servers net share.
Is it possible to automatically get the remote repository updated to tip if somebody pushes its changes?
Because some other people (purely users) may copy the repositories content (rather than cloning, because of lack of .hg) and i want them to get the newest version.
Since it is a share on a simple NAS it would be good if the pushing client could invoke this update.
It seems that a hook on the changegroup event can solve this.
Add the following lines to the repository's configuration file (repo/.hg/hgrc)
[hooks]
changegroup = hg update
This solution was suggested on a slightly different question:
Cloning mercurial repo to the remote host
At least under windows this seems only to work on local repositories. The reason for this is, that hg tries run a cmd on the remote path that fails, since it does not support UNC paths as current direcory.
Adding explicitly the repository url fixes this, but its not client independent anymore.
[hooks]
changegroup = hg update -R %HG_URL%
You could treat the server repository as your "local working directory" and then PULL from your own PC to that location. If you use hg pull --update then it will automatically update the working folder to the latest.
One way to do this is to login to your NAS and physically run the hg command line program there. If not, you could also mount the NAS folder on your local PC and then chdir to its mapped local folder and use your local hg client to do so.
This might seem like an odd thing to do but Mercurial doesn't care which is the "clone" and which is the "server", you can swap them interchangeably in your workflow.
Following is the scenario: I have a remote Mercurial repository at ssh://remotehost//dir/repo and I am able to clone it to a local host "pandora" in directory /home/user/localrepo/.
Now, I have a superset of this remote repository, where I add my own testing framework, but do not want to merge to the main depot until I am certain it works. So I clone this "local" repo to /home/user/workingdir/ but when I issue the command to do so
$ hg clone /home/user/localrepo/
only the repository folder gets copied none of the files get copied.
I'm not sure what you mean when you say that "only the repo folders gets copied". So there's two things you can try :
Try to do a hg update in your new clone.
List the directory in /home/user/workingdir and if there is a directory name localrepo in it, this is actually your repository. To clone in the current directory, you must do hg clone /home/user/localrepo .
This sounds odd but try a few things:
First in the local repo that you cloned from do a
hg status -A
are all the files that you think should be in there in there? If not are you at the tip of the repo.
You can see what revision you are at with
hg parent
If you want to just go to the tip do hg update
If there still aren't any files listed in the repo do the same to check the one on the server.
If there aren't any files on the server you will need to add all of the files you want mercurial to track, mercurial doesn't automagically start tracking files in the repo location.
(Use hg add --all to add all of the file in the entire directory tree under the repo location.)
If there are files in the local repo, check the testing area and make sure that it is on the proper changeset.
Sometimes I have to return to a really old branch when I depended on a ton of external libraries. Updating to the current branch removes the source files for those dependencies, but the artifacts are left there, as well as a few folders and such.
I would like to have a way to force a mercurial repo to be as if I had just cloned it from the remote (master) repository. I don't want to just nuke my repo and re-clone it, because that forces me to download hundreds of MB from the remote server.
Why don't you clone not from remote server, but from your local repository? After that you could nuke your repo with old untracked files.
hg clone path_to_your_local_repo your_new_repo
After this you could map your new repo to your remote server in hgrc file
You can use the purge extension, or if you are on an UNIX-like system: hg st -nu0 | xargs -0 rm.
Let's say the repo I have on my notebook's hard drive is cloned from a remote Repo2 initially, the "all serious" Repo, and then we use Repo1 for tmp storage and code sharing.
So now, what if I do a
hg in ssh://someuser#dev.example.com//code/repo1
and then also on repo2, and see some new changesets on both repos, how do I look at what Peter changed for the 3 files he committed and pushed on Repo1?
And how to do it for Repo2? (on Mac and PC)
What about just looking at the log history?
Is it better that Repo1 and Repo2 both run a process "hg serve" at port 8000 and 8001 for other people to look at history using a web browser?
What if there are no such processes running, then the only way is to ssh to that host and cd to the directory and do hg log and hg diff?
Yes, you must have the repository on your local machine to be able to do hg log and all other commands. Mercurial is a distributed revision control system, and so you are expected to make a local clone before you work with a repository.
Setting up hg serve is a good alternative for when you need to quickly look at the history without cloning it first. But for command line operations, you should make a clone.
I have installed mercurial and review board extension for mercurial on my Windows XP machine. In review board, I have added a repository say "MyRepo" which is on a central server.
I cloned "MyRepo" to my local machine, modified a file for testing and committed to my local repo. I haven't yet pushed it to my central repo.
Now I run "hg postreview" on my cloned local repo. I select "MyRepo" when postreview asks me to choose a repo.
I get a "File not found (207)" error after the command completion. Howver, my review request is uploaded to Review Board server but the diff file is not. Can you tell me what am I doing wrong or is there a patch or command I am not aware of?
I am a novice in DVCS and mercurial, so any help on this matter is really appreciated.
It sounds like you already pushed changes or did more than one commit to the clone (that diffs now more than one commit). Try this and refer to the changeset you created the clone from:
hg postreview -l -o --parent={changeset}
If you wan’t to submit further editings refer to the rewiewid and changeset your first postreview command submitted:
hg postreview -e {reviewid} -o --parent={changeset}