4

Mercurial has an

hg copy file file2

command and the change can propagate change at the first merge. The O'Reilly Mercurial book says that Mercurial is the only source control system that does that.

What is a practical use of this? The book mentioned making a copy of the file and do bug fix, so the bug fix can propagate back to the original file, but with version control, don't we usually edit the file directly, and if the bug fix works, then directly commit that file? Or even if for some reason we need to make a copy, we can cp file file2, test the fix, and mv file2 file to move that file back to the original file, and commit the file. What is a good example of using the hg copy feature?

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
nonopolarity
  • 146,324
  • 131
  • 460
  • 740
  • I've been wondering the same thing. Then I saw someone using it for splitting large files into smaller: http://stackoverflow.com/a/1613196 –  Feb 09 '12 at 12:04

3 Answers3

2

Here's one example I've used personally. Software package with complex configuration files sometimes provide examples with names like universe-wsgi.ini.sample (hi, galaxy), and as part of installation you're supposed to copy the .ini.sample file over to being a .ini file. If you do that using:

hg copy universe-wsgi.ini.sample universe-wsgi.ini

then whenever you update the software with hg pull ; hg update the new settings available in the sample will be added with their defaults to your customized version.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • Our makefiles do this now for some of our own files, it's great to know that hg can handle it so nicely. – Geoffrey Zheng Oct 17 '10 at 01:35
  • It makes sense that this should happen, but I still find it really cool :) – anton.burger Oct 19 '10 at 18:07
  • Hmm, are you sure this is the case? From what I was reading, the hg cp only propagates changes upto the first merge that didn't see the copied file. (http://hgbook.red-bean.com/read/mercurial-in-daily-use.html). That being said it only seems to handle the case where changes were being made simultaneously but not a continuous update like a sample.ini as you describe. So for instance, from my understanding, if you hg copy the file, you commit the change then modify the original, the copy will be untouched. – Gary Jun 05 '12 at 13:23
0

I've seen a lot of confusion on this topic, and admittedly I was too at first. From my understanding, the use case for this is as follows.

If you are making a copy of a file and someone else might be working on the same file at the same time or diverge/branch in a lightweight or actual branch way from a point in time that overlaps with the changesets this file is being copied and possibly modified, this is a candidate for hg copy.

It solves the issue of having a regression in that file from future changes until it is known to exist by the other "heads" of the branch.

What it does not seem used for is:

  • Keeping files periodically in sync and up to date that were copied from the original

The problem gets complicated especially once you get into re-factoring. This would be undesirable to apply changes to a file that was copied a long time ago. It seems like it would only work that way if you kept your development of the copied file in a completely separate branch, but once the two branches are merged back together again, hg copy will no longer do what you expect.

My reference: http://hgbook.red-bean.com/read/mercurial-in-daily-use.html

Gary
  • 1,515
  • 1
  • 14
  • 22
0

Let's say you have a base class in a file. You want to make a derived class so you do an hg copy and customize the derived class by deleting some methods and making changes to others. Now your colleague in another branch has fixed a bug in the base class. When you do a merge, that bug fix will be merged into your derived class as well as your base class.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
  • is it true the timing has to be right? If I create the derived class and check in the code, and he fixed the bug, pull, merge, and commit, then the fix won't be there? It can also break the derived class by the way? Now if it is a config file we are copying, then we probably don't want to use `hg copy` since we don't want one change to propagate to the other. – nonopolarity Oct 16 '10 at 02:35
  • I'm pretty sure it will work whoever does the merge. Yes, it could break the derived class or have another unwanted side effect. That's why you can disable the propagation if you prefer. – Karl Bielefeldt Oct 16 '10 at 03:04