Reputation: 41
I'm part of a team, my current task is restructure, i.e. move around a bunch of files/folders.
I would like to use 'hg mv', but then how to sync it with team work? remember that team is currently working on those files i need to move around. would they be able to pull/update after i push the restructure? Would hg be able to merge their local changes even though i moved their files?
Another issue is 'hg up' in my end before the restructure is being pushed. Can hg deal with incoming modifications on files i've moved, but not yet pushed?
Upvotes: 0
Views: 103
Reputation: 780
Let's make three repositories named main
, tom
and mine
to understand what happens. main
is a central repository where you and Tom(one of your co-worker) push changes and use it to collaborate. tom
is Tom's repository and mine
is your repository. tom
and mine
will obviously be clones of main
.
$ hg init main
$ hg clone main tom
$ hg clone main mine
Let's have a file to play with. Tom created a file and pushed it to the main repository.
$ cd tom
tom$ echo 'print hello' > a.py
tom$ hg add
tom$ hg ci -m "Added a.py"
tom$ hg push
pushing to /home/main
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
Now you get started by pulling the changes.
$ cd mine
mine$ hg pull
pulling from /home/main
requesting all 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)
mine$ hg up
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Now you notice that Tom is not good at naming as he named the file as a.py
which is least descriptive. You decided to rename it to hello.py
.
mine$ hg mv a.py hello.py
mine$ hg ci -m "Rename a.py to hello.py"
At the same time, Tom ran a.py
and realised that quotes (print hello
must be print "hello"
) are missing. He fixed that and pushed another commit. You decided to pull that one before you push.
mine$ hg pull
pulling from /home/main
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
mine$ hg merge
merging hello.py and a.py to hello.py
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
mine$ hg ci -m "Merge commit"
Now when you look at hello.py
, you find the fix by Tom is present and you decided to push.
mine$ cat hello.py
print "hello"
mine$ hg push
pushing to /home/main
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files
Let's switch back and see how things will be happening after this push on Tom's side. Tom made one more change locally which he didn't pushed. The change was about adding parentheses to print function.
tom$ hg pull
pulling from /home/main
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
tom$ hg merge
merging a.py and hello.py to hello.py
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
tom$ hg ci -m "Merge heads"
tom$ hg push
pushing to /home/main
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 2 files
When you will pull this time, your are Tom repository will have the same state with file renamed and all the changes intact.
mine$ hg pull
pulling from /home/main
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 2 files
(run 'hg update' to get a working copy)
$ hg up
$ cat hello.py
print("hello")
You can see that the change which added parentheses is also there. So its very safe renaming files in Mercurial using hg mv
.
Upvotes: 1