I have a code on F # in my Desktop and would like to pull it to Kiln mercurial repository on https://www.kilnhg.com/. I do the following.
1) change directory to the path of my code
2) hg clone https://....kilnhg.com/Code/goyal-welch/Group/goyal-welch (repository on Kiln)
What should I do next to push the code on my computer to this Kiln mercurial repository? Any lead way will be tremendously appreciated.
You've probably solved it by now, but here goes:
From the directory:
hg add . // Adds all files in the current directory
hg commit -m "Your comments" // Creates a new changeset
hg push // Pushes the changeset to the server
Related
Currently my company is using cvs for version control. I want to use mercurial locally because of it's flexibility and merging capabilities. This will make my job a lot easier.
How should this be done?
First: Get the CVS repository locally.
Second: Create a mercurial repositories locally over this CVS repository. This will be used as your remote mercurial server.
Third: Clone this mercurial repository and do you work here.
Mercurial provides better merge support than cvs and will make your work easier. Commit back to CVS needs an extra step. Here is how this works, step-by-step. The workflow looks complicated, but is actually easy. Keep the flow-charts close.
1) Local CVS repository: Create a local repo with CVS checkout.
2) Remote HG repository: Make a mercurial repo over this CVS repo. (HG init; HG add; HG commit). The repo will be used like a remote mercurial repository. Keep this folder clean and use this only to transfer files from-and-to CVS.
3) Local HG repository: Create a new folder where you will do all your work. (HG clone). Add all CVS files to the hg-ignore-list.
4) Development: Do the work here and ‘hg add/commit’ when needed.
Preparation before pushing your work back to CVS: (step 5-8)
5) CVS update: (local CVS repository = remote HG repository)
CVS update: Update the local CVS repository
hg commit: Commit the CVS updated code in the remote mercurial branch
hg update: Update your working copy to make the CVS changes active.
6) HG pull: Check for changes on your local mercurial repo and pull the changes.
7) HG merge: Merge all CVS changes on your local mercurial repo. Most changes will merge automatically.
8) HG commit: Commit your changes after merge.
Now you are ready to push your work to the remote HG repo and CVS.
9) Local HG push: Push your local work to the remote repo.
10) Remote HG update: Update to let your working copy view the pushed changes.
11) CVS commit: Commit the changes in your remote mercurial repo to CVS with a CVS commit.
2 view on this work:
Step-by-step:
Container view:
I just lost my .hg* files for my repository after a migration and I have made a bunch of unpushed changes to some code.
I need to Init a new repository and then push my changes to an existing remote repository. Do I just need to init a new repo and then specify the remote repo in the hgrc and push? Thanks!
If you remember the changeset you had in your original repo as its working parent (let's call it A), then you can do this:
$ hg clone http://server/upstream newrepo
$ cd newrepo
$ hg up A
Then copy the working copy of the original repo to the new repo (with an additional precaution of deleting all files from the new repo if you renamed / deleted anything in the old repo). Afterwards, commit and push from the new repo:
$ hg commit
$ hg push
If the upstream repo has anything on top of A, rebase or merge before pushing.
I am familiar with TFS and Vault, but having just started using Mercurial I seem to be getting into a bit of a mess.
Heres what I (think) I've done:
-Created a central repository on bitbucket.org
-On my desktop PC, cloned repository from bitbucket, added files, commit them, push them to bitbucket
-On my laptop, cloned repository from bitbucket, pulled files, added more files, commit them, push them to bitbucket
I've continued to add, edit etc on the different computers.
Now I've noticed that some files from each computer are not in the bitbucket repository, and therefore only in the local repository. No amount of pulling and pushing seems to get it into the bitbucket repository.
What is the most likely thing I've done wrong?
Is there a way to 'force' by changes up to the bitbucket repository?
Did they get into your local repository? I suspect not, i.e. they were new files that were not added to the commit. Use hg add to add them to the changeset before committing or whatever the equivalent is for whatever mercurial interface you're using.
Edit:
Here's the help from Mercurial:
C:\Users\Bert>hg add --help
hg add [OPTION]... [FILE]...
add the specified files on the next commit
Schedule files to be version controlled and added to the repository.
The files will be added to the repository at the next commit. To undo an
add before that, see "hg forget".
If no names are given, add all files to the repository.
...
See Mercurial: The Definitive Guide (a.k.a. the hg "red book") for more info:
http://hgbook.red-bean.com/read/mercurial-in-daily-use.html
Telling Mercurial which files to track
Mercurial does not work with files in your repository unless you tell it to manage them. The hg status command will tell you which files Mercurial doesn't know about; it uses a “?” to display such files.
To tell Mercurial to track a file, use the hg add command. Once you have added a file, the entry in the output of hg status for that file changes from “?” to “A”.
$ hg init add-example
$ cd add-example
$ echo a > myfile.txt
$ hg status
? myfile.txt
$ hg add myfile.txt
$ hg status
A myfile.txt
$ hg commit -m 'Added one file'
$ hg status
use "hg -v help add" to show global options
I am looking for best practices to do the following:
When I need to implement a feature or fix a bug, I am creating new Mercurial repository from the main one (a trunk).
Then, within some days, or weeks, I am implementing the task in newly created repository, making commits and periodically merging with trunk. After the code in new repository will pass all code reviews, I should provide a repository with all changes collapsed into single revision.
My common way to do this (rdiff extension should be enabled):
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg diff ~/repos/new > new.diff
patch -p1 < new.diff
hg commit
This works almost well except when there are binary files present in the changes from ~/repos/new. Another way could be:
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg pull ~/repos/new
hg update
hg rollback
then resolve possible conflicts and manually commit the changes
Both ways look for me somewhat ugly and non-native, so I am looking how this operation could be simplified. I've played with rebase extension, but seems its hg rebase --collapse command does not work with workflow described above.
Any ideas are welcome.
Sounds like a good case for mercurial queues.
I do something similar with the histedit extension.
My workflow is something like:
clone a central repo
commit incremental changes to local repo
clone my local repo to make collapsed repo
hg histedit and select/discard/fold the revisions as needed
hg push the collapsed repo to central repo
pull central repo to local or refresh local from scratch
I ensure that my local repo never gets pushed to the central repo by adding an invalid default-push path to the .hg/hgrc file in the local repo root directory.
Solved: Just add
[diff]
git = True
to your hgrc file, and then use my first solution with rdiff extension, replacing patch with hg import:
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg diff ~/repos/new > new.diff
hg import new.diff
hg commit
When a project is started with
mkdir proj
cd proj
hg init
[create some files]
hg add file.txt
hg commit
hg push ssh://me#somewhere.somehost.com/proj
now when hg path is issued, nothing will show. How do we actually change the repository so that it is as if it is cloned from me#somewhere.somehost.com/proj ? Is it just by editing .hg/hgrc and adding
[paths]
default = ssh://me#somewhere.somehost.com/proj
because that feels like too low level an operation to do (by editing a text file)
It's the only way to do it in this situation. There are plenty of other cases where you have to edit the hgrc by hand, like setting up hooks or enabling extensions, so it's not as if it's unusual.
(As you probably already know, hg clone will set the path entry in the clone to point back to the original.)