I have a mercurial repo structured as follows:
/parent
/child1
/child2
with the following webconfig file for hg serve:
[paths]
/ = ./*
/parent/child1 = ./parent/child1/*
/parent/child2 = ./parent/child2/*
[web]
allow_push = *
push_ssl = false
I want to be able to clone /parent/child1 or /parent/child2 and update them, then later clone /parent and have all the changes from the children. Preferably showing the commits for the children as well.
I'd also like to be able to easily add /grandchild to one of the children at any time and have it function the same as the children (can clone parent or child folder and get all changes)
The current setup will let me clone the children as I want, but any changes are not reflected in the parent repository.
I'm using hg server --web-config to serve these repos.
I believe I need to use .hgsub to achieve these results, but I'm not sure how and most of the places I find with info link to the old mercurial website, which now doesn't exist.
Other subrepo related configs I've found are just for mapping /parent/child1 to /child1 (I will have a lot of subrepos that may be named similar or the same, so I'd prefer not to have each available in the base) or for mapping someone else's repo as a dependency.
This is an example of what I'd like to be able to do (cmd example):
hg clone http://server/parent/child1 child1
cd child1
echo changes >file1.txt
hg commit -m "changes to child1"
hg push
cd ..
hg clone http://server/parent parent
cd parent/child1
echo new changes >>file1.txt
hg commit -m "changes to child1 again"
hg push
cd ../../child1
hg pull -u
type file1.txt
which should print
changes
new changes
Is this possible with mercurial serve? How can I achieve what I want with a web config? I'm still setting up my mercurial server, so I don't need to worry about history.
If it's not possible, is there another version control software that can do as I need?
Related
I have got a question regarding suprepositories. Our project is set up like this:
+ projectA
+ some files
+ dependencyA
+ some files
dependencyA is a subrepository. It was created this way:
cd projectA
mkdir dependencyA
cd dependencyA
hg init
hg pull ssh://hg#somerandomiphere/dependencyA
cd ..
echo dependencyA = ssh://hg#somerandomiphere/dependencyA > .hgsub
hg add
hg commit
hg push
If I make changes to the suprepository, then commit and push them from main project. Both of them will be pushed to the server since its recursive. Now my colleague wants to pull changes from the server. But since nothing was changed in the main project, it wont work. But if I change something in the main project and push it to server. Upon hg pull he will get the newest changeset and if he does hg update then, it will update the subrepository as well. This is expected behaviour.
Now my question would be, if there is a way to pull changes, but only for subrepository without making a new clone of it or what would be the best way to do it.
Subrepository in Mercurial wiki, p. 2.5 "Pull"
The 'pull' command is by default not recursive. This is because
Mercurial won't know which subrepos are required until an update to a
specific changeset is requested. The update will pull the requested
subrepositories and changesets on demand. To get pull and update in
one step, use 'pull --update'.
Note that this matches exactly how 'pull' works without
subrepositories, considering that subrepositories lives in the working
directory:
'hg pull' gives you the upstream changesets but doesn't affect your working directory.
'hg update' updates the contents of your working directory (both in the top repo and in all subrepos)
It might be a good idea to always pull with --update if you have any
subrepositories. That will generally ensure that updates not will miss
any changesets and that update thus not will cause any pulls. If the
pull with update fails due to crossing branches then 'hg update' must
be used to get all the subrepository updates.
What was suggested above works like I thought it would. The real problem was my way of creating a subrepository.
Instead of:
cd projectA
mkdir
dependencyA
cd dependencyA
hg init
hg pull ssh://hg#somerandomiphere/dependencyA
It should have been a simple:
hg clone ssh://hg#somerandomiphere/dependencyA dependencyA
As we know .hgsusbtate will lock the subrepo on specific revision after commit. This is what happened, but (!) doing hg pull in subrepository ended with an error
paths cannot contain dot file components
So this means my subrepo was locked on the revision it was updated after commit and it could not pull changes from its repository due to the error shown above. Why this happened is explained pretty well in this accepted answer.
Solution:
cloning is the way to go
We're using a local central repository where everyone pushes to and pulls from. Until recently this repository only contained the .hg folder. Then someone went ahead and committed directly in the central repository creating an "island" changeset with no parent (parent = -1) nor child. The correct way would have been to add it in a local repository and push the changes.
Is there any way to get the working copy of the central repository to get back to the state where it only contain .hg and not be associated with a specific changeset?
The command:
hg update null
Updates a repository's working directory to the point before the first commit, so there are no files in the working directory and hg parents shows -1.
You'll still need to remove the commit if you don't want it, but that's a separate question/issue.
Since this is your local central repository and these are commands that edit history, please take every precaution, like trying things out on a copy of the repository first.
hg rollback (to remove the last repository change)
https://www.mercurial-scm.org/wiki/Rollback
Roll back the last transaction in a repository.
hg strip (to remove specific revisions)
https://www.mercurial-scm.org/wiki/Strip
hg strip rev removes the rev revision and all its descendants from a repository.
Also see:
https://www.mercurial-scm.org/wiki/EditingHistory
If you catch your mistake immediately (or reasonably soon), you can just use hg strip REV to roll back the latest (one or more) changes. ...
Edit: This answers the question in its original form. The OP has since edited the question.
Just delete everything except the .hg folder.
If I understand correctly what happened, someone changed into the repository directory and committed a single file as an 'added file' without first checking out any changeset from the active directory.
What you ended up with is something like the following history graph:
0:a43f 1:2843 2:bc81 3:2947
o ------ o ------ o ------ o
4:228f
o
where changeset 4:228f has the "null id" as its parent changeset.
Depending on whether you want to keep changeset 4:228f or not, you can follow one of the following strategies:
Option 1: Clone the repository without the offending change
You can create a new clone of the repository, specifying revision 3:2947 as the target revision. This will pull change 3:2947 and all its ancestor changesets into the new repository. Since the offending changeset is not linked into the ancestry of changeset 3:2947, it will not be part of the new clone.
I recommend saving the old repository first, and then moving everything over to a new clone, e.g. any repository-specific setup files you keep in its .hg/ directory.
If your current repository lives in /work/repo/foo, one way to do this would be:
$ cd /work/repo
$ mv foo foo.bak
$ hg clone -r 2947 foo.bak newfoo
Now copy over any .hg/ setup files, e.g. your original .hg/hgrc file:
$ cp foo.bak/.hg/hgrc newfoo/.hg/hgrc
Finally move the new foo repository in place:
$ mv newfoo foo
Option 2: Clone the repository and keep but rebase the change
Do the same as before, but before you move the newfoo repository in place, use the "hg export" command to extract a copy of the offending change from the old repository. Then check out a working copy of the tip-most changeset in the newfoo tree and import the file changes of the offending change as a normal changeset of your current history graph.
So, right before mv newfoo foo, save the patch of the offending change by typing:
$ cd /work/repo/foo.bak
$ hg export -r 228f --git > /tmp/patchfile.diff
then you can check-out the latest revision of the new repository, and re-import the patch on top of your current history:
$ cd /work/repo/newfoo
$ hg update --clean tip
$ hg import /tmp/patchfile.diff
If the offending changeset merely adds a new file, this should work fine and you are ready to move the new repository in place!
Before doing the final rename though, it may be a good idea to remove the working-copy files of the new repository:
$ cd /work/repo/newfoo
$ hg update --clean null
I have come across a problem that I "think" can only be resolved using patches.
I cloned a project from our main repository, made quite a few changes (updates, deletion of files & directory and additions) to it. These changes are not even committed. The problem is, project from the main repository has been deleted/removed and recreated as a new project (name is same, all the directory structures everything is same as before). I cloned that project again from the main repository and would like to transfer all my uncommitted changes to it.
I am still exploring the hg patch to resolve that. It would be helpful if someone could confirm that creating and adding a patch IS the right approach to this, any resources explaining the process would be of great help.
You're correct — a patch is what you need to transfer the information from one repository to another (unrelated) repository. This will work since the files are the same, as you note.
So, to transfer your uncommitted changes from your old clone, you do
$ hg diff -g > uncommited.patch
$ cd ../new
$ hg import --no-commit ../old/uncomitted.patch
That will restore the information saved in the patch. This includes information about files that are added or renamed in the old clone.
The following steps can be performed with a standard Mercurial install:
Commit the changes in your local repository. Note the revision number.
Use "hg export -r REV >patch.diff" to create a patch.
Clone the new repository.
Use "hg import patch.diff" to apply the patch to the new repository.
Example
C:\>hg init example
C:\>cd example
C:\example>echo >file1
C:\example>hg ci -Am file1
adding file1
C:\example>hg clone . ..\example2
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\example>rd /s/q .hg
C:\example>hg init
C:\example>hg ci -Am same-but-different
adding file1
At this point example and example2 have identical contents, but the repositories are unrelated to each other due to deleting and reinitializing the .hg folder.
Now make some changes and commit them in one of the repositories, then export them as a patch:
C:\example>echo >>file1
C:\example>echo >file2
C:\example>hg ci -Am changes
adding file2
C:\example>hg export -r 1 >patch.diff
Below shows that the other repository can't pull the changes, because of the reinitialization. It can, however, apply the patch successfully:
C:\example>cd ..\example2
C:\example2>hg pull
pulling from c:\example
searching for changes
abort: repository is unrelated
C:\example2>hg import ..\example\patch.diff
applying ..\example\patch.diff
I would first make copies of everything so you have a way of backtracking.
Then, in the working copy with the changes, I would first delete the .hg directory, then copy in the .hg directory from the new repo. This basically transfers all of the changed files into the new repo without the need to delete any files and directories.
You will still need to tell the repo about whether to remove any files marked as missing. You will also have to handle renames manually. If this is a small number of operations, it's easier than trying to use the patch method.
Once this is done, commit your changes and push, if necessary.
seems like what you want is patch queues. In that you have uncommitted changes, and you want to pull from the new repo before committing them....
$ hg qinit -c # initialize mq for your repo containing the uncommitted changes
$ hg qnew name_of_patch # create patch that contains your uncommitted changes
$ hg qpop # resets your working dir back to the parent changeset
no worries though, your changes are safe and sound in .hg/patches/name_of_patch to see for yourself.....
$ cat .hg/patches/name_of_patch
now pull in the new repo
$ hg pull -u http://location.of.new/repo # pull in changes from new repo update working dir
$ hg qpush # apply your uncommitted changes to new repo
If you are lucky you will have no merge conflicts and you can go ahead and commit the patch by....
$ hg qfinish -a # change all applied patches to changeset
And then if you want....
$ hg push http://location.of.new/repo
If the repos are unrelated, just init a patch repo on your new repo. and manually copy the patch in and add it to .hg/patches/series file.
assuming patch was created. clone new repo
$ hg clone http://location.of.new/repo ./new_repo
init patch repo
$ cd ./new_repo && hg qinit -c
copy patch
$ cp ../old_repo/.hg/patches/name_of_patch .hg/patches/
edit series file using an editor of some sort
$ your_favorite_editor .hg/patches/series
name_of_patch # <---put this in the series file
apply your patch to new repo
$ hg qpush
if no merge conflicts and you are convinced it works
$ hg qfinish -a
If the layout is the same, you can just copy all the files over (excluding .hg) and then use hg addrem.
Try to look into the MQ plugin, it does exactly this if I recall. I've never had a use for that though, so I can't say.
If the old repository was simply moved/cloned to a new URL then you could simply change the remote repository you talk to the new one.
If, however, it was recreated from the ground up (even with the same structure) then I don't believe Mercurial has any built-in functionality to help you here. Mercurial patches reference specific changesets which won't exist in your new repository.
You could use a merge tool to perform the diff and bring across any changes you made.
Edited To answer the question in the comment:
When you clone the repository you are taking a complete snapshot of the entire change history - along with the associated change-set IDs, etc.
Mercurial tracks changes by change-sets to the repository, rather than at the file level like Subversion.
If you clone, then you can easily push/merge into another repository that was also cloned from the same source.
If you recreated the repository then the change IDs won't match, and can't be merged in Hg.
The only option in this scenario would be to use a Merge tool which will let you see mismatches in files/folder structure.
Also: Worth pointing out http://hginit.com/ because it explains (indirectly) some of this.
Is there a way to clone a repo that comes with subrepos, but without having Mercurial pull all the subrepos?
It appears that while hg clone -U can be used to obtain an empty clone of a repo, there's nothing that would convince hg update to avoid starting off by pulling all of the subrepos.
I should point out that it is crucial to retain the ability to easily sync to the head revision after creating such a clone.
This should do what you want:
REM Take a new clone, but do not update working directory
hg clone --noupdate %REPO_PATH% %DESTINATION%
REM Update working directory but exclude the certain subprojects
hg revert --all --rev %BRANCH% --exclude %SUBREPO_PATH_1% --exclude %SUBREPO_PATH_2%
This answer may add more than the question required, but provides some valuable notes on working with Mercurial when you can't update do to a bad subrepository path or revision.
Step 1: Clone the repository without any updates
hg clone --noupdate source_repository destination_repository
Step 2: Use revert to get the right files
hg revert --all --rev revision_number --exclude subrepo_1 --exclude subrepo_2 ...
At this point, you have a new changeset; you may need to make sure the parent revision is correct. When I did this, my new changeset's parent was changeset 0. To fix this I had to set the parent changeset AND switch branches (since my changeset was on a different branch).
Step 3: Change the parent of the current changes
hg debugsetparents revision_number
hg branch branch_name
That should do it.
Found a hacky way. It still requires all subrepos to be checked out once, but afterwards they can be deleted.
Clone the whole lot, including subrepos. No way around this.
Delete subrepos
hg remove .hgsub
I tried to convince Mercurial to hg remove .hgsub before the subrepos are cloned, but the best I got is not removing .hgsub: file is untracked.
If you have a subrepo, a working directory must include some version of that subrepo. That version may be a fixed older revision if specified, or the tip if not.
You cannot update your repo without getting the subrepos; if you had a complete working dir without them, you shouldn't be using subrepos - use truly external repos instead.
If your subrepos are pegged against a certain remote version, then updates after the first will not trigger a subrepo update - they're already up-to-date. But for the initial creation of the working directory, you will have to do a remote pull.
You can trick Mercurial by munging the hgsubstate file. But really, your model and the conceptual model differ, so you're probably not a good match for subrepos if this is a concern.
edit: If you find yourself cloning and then updating to the tip many times, try using local branches or mq instead. That way you only have to do the initial clone once.
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.)