So I've verified from several sources that hg update -C <branch> is the approved way to switch branches in Mercurial. However, it doesn't seem to be doing the job for me:
Firefly:templatedoc Ken$ hg branches
IntCursor 7:1aec742eb390
default 6:bf3fba585a57 (inactive)
Firefly:templatedoc Ken$ hg update -C default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
Firefly:templatedoc Ken$ hg branches
IntCursor 7:1aec742eb390
default 6:bf3fba585a57 (inactive)
Thank You!
Ken
Related
What is the best way to check which branch I am on with mercurial?
hg log -l 5
This seems to show me the latest commits in the repo and not about working state as git would, so I'm looking for something like git status I suppose, which would tell me what branch I am on. hg status doesn't show me anything.
You can use the hg identify command with the -b for branch option:
C:\Some\Repository> hg identify -b
default
hg branch. I suggest at least reading hg help once :^)
$ hg branch
You can just always use the grep with a keyword to search.
In this case,
$ hg help | grep branch`
Gives you:
branch set or show the current branch name
branches list repository named branches
graft copy changes from other branches onto the current branch
heads show branch heads
You could use hg sum
for example, say you have two branches, A and B
[root#B6LEB1 ATS]# hg update A
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
[root#B6LEB1 ATS]# hg sum
parent: 1787:3f06e1a0260a
made A
branch: A
commit: (clean)
update: (current)
[root#B6LEB1 ATS]# hg update B
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
[root#B6LEB1 ATS]# hg sum
parent: 1788:7ff3c507efd9 tip
made B
branch: B
commit: (clean)
update: (current)
You also might want to specify the currently checked-out version explicitly. Then the output of hg log will return what you look for:
hg log -r.
When I'm trying to change the branch where I am, I'm getting this error everytime:
# Just check in which branch I am
$ hg branch
django1.6
$ hg update --clean default
abandon: Unlinking directory not permitted: 'D:\Projects\abc\abc'
(abc is the project name, replace for simplicity here). Since it's a Django project, named abc, I have a subfolder abc that I have created in the django1.6 branch. This folder doesn't exist yet in the default branch, so if I'm changing the branch, the folder has to be deleted in theory
When I check the properties, I see the folder is in read-only mode, so in cygwin I chmod the folder and try again...
$ chmod -R 0777 hstareal/
$ hg update --clean default
abandon: Unlinking directory not permitted: 'D:\Projects\abc\abc'
$ hg update --clean another-already-existing-branch
abandon: Unlinking directory not permitted: 'D:\Projects\abc\abc'
For information, I can create a branch and get back to django1.6 without problems:
$ hg branch test
marked working directory as branch test
(branches are permanent and global, did you want a bookmark?)
$ hg update --clean django1.6
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
Does anyone see where the problem is? I'm sure it's something related to cygwin, but I can't see why.
The single workaround I found for the moment is to delete the folder by hand and then update the branch.
$ rm -rf abc/
$ hg update --clean default
27 files updated, 0 files merged, 4 files removed, 0 files unresolved
Really dirty but at least it works... I'm still listening to better suggestions :)
I have numerous projects with subrepositories:
/project <- Main repository
/project/src <- Source code subrepository (subrepository to /project)
/project/src/module <- Module subrepository (subrepository to /project/src repository)
I've now worked on a feature branch (feature1) which has had a few revisions, which I'd now like to merge back into the default branch. The default branch hasn't had any changes since the feature1 branch was created.
I've tried merging the branch to default however end up with some strange things happening in the subrepositories.
I've followed the instructions in this other post, and get the following results:
$ hg checkout default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg merge feature1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg status -S
M .hgsubstate
$ hg commit -S -m "branch merge test"
nothing changed
$ hg branches
default 19:c2398dc23428
feature1 17:98dc0efbad90 (inactive)
What's strange is that even though many files were changed in the module subrepository, the merge only stated that 1 file was updated. I'm assuming that this happens to be the .hgsubstate.
When I explicitly update the subrepository, then I get the following:
$ cd src/module
$ hg update
39 files updated, 0 files merged, 23 files removed, 0 files unresolved
$ cd ../..
$ hg commit -S -m "feature1 merge"
committing subrepository src
$ hg status -S
M .hgsubstate
So after doing a hg update to bring all the changes into the working directory, I see the changes in the module subrepository that I need to commit. However, .hgsubstate always remains in the modified state. I've tried hg remove. I've tried hg forget. But no matter what I do, it still is marked when I do a hg status.
So my questions are:
Was the process I took to merge the branch in correct (considering subrepositories are present)?
Is it necessary to do a hg update in the subrepositories to make the main repository recognize the changes?
Why is .hgsubstate misbehaving?
You don't say which version of hg you are using - subrepo support has changed a certain amount over time. I've just tried something like your test with 3 subrepo levels in hg v2.8 and it works for me.
When you got a dirty .hgsubstate at the top level, that is normal when you commit a subrepo. [If only a subrepo has been committed independently, only the .hgsubstate will be dirty at the top level.] If you then go up to the top level and commit at that level the .hgsubstate will be committed, and everything is fine. Remember, the top level repo tracks subrepos in a similar fashion to files - it commits a particular changeset from the subrepo at each top level commit.
FWIW. The recommended practice is to commit subrepos separately, i.e. avoid committing at the top level if the subrepos are dirty. The reason is that the subrepos often require a different commit message - they are subrepos for a reason after all; but you can commit at the top level if you wish. In your case with 3 levels the sequence would be:
cd src/module
hg commit -m "src/module commit reason"
cd ..
hg commit -m "src commit reason"
cd ..
hg commit -m "top level reason"
It was intended that subrepos would change infrequently, e.g. third party libraries. If your subrepos are going to change frequently, you and your team will have to be vigilant to avoid mistakes, especially when merging with other peoples work. [But given the date of the question you've probably worked that out yourself by now.]
I'm setting up a Mercurial repository to track third-party code, roughly following the vendor-default branch scheme described in Rudi's answer to this question. In order to quickly retrieve a particular version, I create tags for each vendor and default version.
I initialize the repo by committing an empty .hgtags to establish the default branch, then I hg branch vendor and import the first version. The process to add a new version looks like this:
hg up -C vendor
... load new version ...
hg commit -A -m "Adding version x.y.x"
hg tag vendor-x.y.z
hg up -C default
hg merge vendor
hg commit -m "Merging version x.y.z"
hg tag x.y.z
During the merge I always keep the local copy of .hgtags, so the result is that the vendor branch has .hgtags containing all the vendor-x.y.z tags while the default branch .hgtags has only the x.y.z tags.
It's my understanding that Mercurial considers .hgtags from all heads when working with tags. Yet when I run hg tags the result contains only tip and the x.y.z tags. This is the same regardless of which branch my working directory is updated to; it's always the tags from the default branch .hgtags file.
I can update to the vendor-x.y.z tags, so Mercurial does see their existence, but the update appears to give me code from the vendor branch tip. The x.y.z tags work fine.
I've worked mainly with Git and SVN/CVS in the past, so I assume that this is a problem of understanding, not a technical issue. I did try it, just in case, on two versions of Mercurial (2.0.2 and 2.3.2) and got the same results.
I'm not in front of my Mercurial system to verify, but I think the issue is Mercurial only considers .hgtags from topological heads, not branch heads. Example:
[1]---[2]---[5]---[6] Default
\ /
[3]---[4] Vendor
[6] is a topological head, [4] and [6] are branch heads. The solution is to keep all changes to .hgtags on a merge.
Edit
Here's my test. Directly after the merge I accepted the local .hgtags and hg tags only displays the tag on default. I can't update to the vendor tag, which differs from what you are seeing. I'm using Mercurial 2.3.1. After creating another changeset on vendor and making a second topological head, the missing tag reappears.
hg init test
cd test
echo >a
hg ci -Am 1
hg branch vendor
echo >b
hg ci -Am 2
hg tag v1
hg update default
hg tag d1
hg merge vendor --tool internal:local
hg ci -m Merge
#REM This only shows 'tip' and 'd1'
hg tags
hg update vendor
hg tags
hg update d1
#REM This fails to update.
hg update v1
# Add another topological head by committing to vendor
hg update vendor
echo >c
hg ci -Am 3
# Now all tags are visible and work.
hg tags
hg update v1
hg update d1
And the output:
C:\>hg init test
C:\>cd test
C:\test>echo 1>a
C:\test>hg ci -Am 1
adding a
C:\test>hg branch vendor
marked working directory as branch vendor
(branches are permanent and global, did you want a bookmark?)
C:\test>echo 1>b
C:\test>hg ci -Am 2
adding b
C:\test>hg tag v1
C:\test>hg update default
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
C:\test>hg tag d1
C:\test>hg merge vendor --tool internal:local
1 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
C:\test>hg ci -m Merge
C:\test>hg tags
tip 4:80759c41b3cc
d1 0:17b05ed457d1
C:\test>hg update vendor
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\test>hg tags
tip 4:80759c41b3cc
d1 0:17b05ed457d1
C:\test>hg update d1
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
C:\test>hg update v1
abort: unknown revision 'v1'!
C:\test>hg update vendor
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\test>echo 1>c
C:\test>hg ci -Am 3
adding c
C:\test>hg tags
tip 5:a2c0fe73a9f1
v1 1:3168d0f4e5e5
d1 0:17b05ed457d1
C:\test>hg update v1
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
C:\test>hg update d1
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
In our repository we have initial version of database (binary file).
I have executed hg pull and I saw that someone committed another version of this file.
As I won't to loose my changes in dev db, I did make a copy of it (copy file.db my_file.db) in same directory.
When I runned hg up, mercurial overwrited file.db with new version and deleted my_file.db!
I'm on windows 7 x64, and tried various software that recover deleted files, but with no success.
How can I get back my version of file.db or recover my_file.db? I didn't commit it.
I really don't think mercurial deleted your untracked file. Here's the sequence you've described as I understand it:
ry4an#four:~$ mkdir zote
ry4an#four:~$ cd zote
ry4an#four:~/zote$ hg init orig
ry4an#four:~/zote$ echo text > orig/file.db
ry4an#four:~/zote$ hg -R orig commit -A -m 'initial'
adding file.db
ry4an#four:~/zote$ hg clone orig clone
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
ry4an#four:~/zote$ mv clone/file.db clone/my_file.db
ry4an#four:~/zote$ echo more text >> orig/file.db
ry4an#four:~/zote$ hg -R orig commit -m 'new line'
ry4an#four:~/zote$ hg -R clone pull
pulling from /home/ry4an/zote/orig
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
ry4an#four:~/zote$ hg -R clone update
remote changed file.db which local deleted
use (c)hanged version or leave (d)eleted? c
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
ry4an#four:~/zote$ ls clone/
file.db my_file.db
ry4an#four:~/zote$ cat clone/my_file.db
text
ry4an#four:~/zote$ hg -R clone status
? my_file.db
You can see that afterward my_file.db is still there. Even with --clean as Mikezx6r mentiones the file is still there:
pulling from /home/ry4an/zote/orig
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
ry4an#four:~/zote/clone$ hg update --clean
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
ry4an#four:~/zote/clone$ ls -l
total 8
-rw-r--r-- 1 ry4an ry4an 15 2011-02-08 14:31 file.db
-rw-r--r-- 1 ry4an ry4an 5 2011-02-08 14:28 my_file.db
ry4an#four:~/zote/clone$ hg stat
? my_file.db
ry4an#four:~/zote/clone$
It's not what you want to hear, but it's much more likely you accidentally botched the 'mv' and only thought you created the copy or somehow externally deleted it. Or your antivirus app saw a pattern it didn't like a refused to create it, or some other horrible, accidental thing.
It's also not helpful now, but this is a great example of why you should commit early and often, and especially before updating -- it's just too easy to make mistakes, but once something in in the repo there's nothing you can do to accidentally remove it.