Question

From Mercurial wiki – GSoC Ideas 2010:

Project Ideas

Lightweight copies/renames

(very difficult – a successful student
will become an expert in Mercurial’s
storage format and transmission
protocol)

Copies and renames currently are not
too efficient. Mercurial copies the
copied/renamed source file to the new
initial revision of the target file in
its internal history store. For
renames, this is especially
counter-intuitive, as renaming a large
file grows the store by the file’s
size. It would be better if Mercurial
had some way of referring to the
existing revision from the new file,
while preserving backwards
compatbility and bounded I/O
guarantees for retrieving revisions.
See issue883 for discussion.
There’s an mq from an old attempt at
this located here.

Sorry if this is an obvious question (I’m not good at English and programming). I’m wondering, what does the "Lightweight copies" mean?

Is it mean: when this feature is implemented, multiple files with same content (same hash value different file names) will be stored only once in repository (just like Git)?

---

Update:

Thanks everyone for your answers. One of Mercurial’s developers – tonfa also answered this question in a comment of this answer:

caveman: When light-weight copies are
implemented, will two files with same
content (same hash value different
names) store only once in repository
(just like Git)?

tonfa: no, this feature isn’t planned
(it would break other optimizations to
minimize disk access)

Answer 1

Right now, when you copy a file, a new file is created in the repository that contains a compressed snapshot of the file you just copied. The idea would be to set it up so the copy references the old file somehow and then has revlog entries based on that instead of having to have its own snapshot to base the revlog entries off of.

This will not be like how git works. Changing Mercurial to work that way would be really interesting, and not the easiest proposition.