Mercurial: Lightweight copies/renames -


from mercurial wiki - gsoc ideas 2010:

project ideas

lightweight copies/renames

(very difficult - successful student become expert in mercurial's storage format , transmission protocol)

copies , renames not efficient. mercurial copies copied/renamed source file new initial revision of target file in internal history store. renames, counter-intuitive, renaming large file grows store file's size. better if mercurial had way of referring existing revision new file, while preserving backwards compatbility , bounded i/o guarantees retrieving revisions. see issue883 discussion. there's mq old attempt @ located here.

sorry if obvious question (i'm not @ english , programming). i'm wondering, "lightweight copies" mean?

is mean: when feature implemented, multiple files same content (same hash value different file names) stored once in repository (just git)?


update:

thanks answers. 1 of mercurial's developers - tonfa answered question in comment of this answer:

caveman: when light-weight copies implemented, 2 files same content (same hash value different names) store once in repository (just git)?

tonfa: no, feature isn't planned (it break other optimizations minimize disk access)

right now, when copy file, new file created in repository contains compressed snapshot of file copied. idea set copy references old file somehow , has revlog entries based on instead of having have own snapshot base revlog entries off of.

this not how git works. changing mercurial work way interesting, , not easiest proposition.


Comments

Popular posts from this blog

c# - how to write client side events functions for the combobox items -

exception - Python, pyPdf OCR error: pyPdf.utils.PdfReadError: EOF marker not found -