Tracking files and file-level operations

[Chris Hecker]

Sorry, I meant as a first class operation.   Lacking a "rename" or "mv" 
command is not what I meant.   As far as I know, rename is implemented 
as a copy+delete in hg, like svn.  My understanding (and I'm not an 
expert on bzr or hg), is that hg does a better job with its 
implementation of rename than svn, but it's caused me no end of trouble 
with svn over the years (and others, the infamous bug #898), and so I 
was relieved when I found out bzr has renames as a first class 
operation, and also directories as first class renamable entities, which 
is a somewhat related topic.

There were other reasons I chose bzr as well, and this isn't the place 
for that, but at least reading what's available on the net, bzr's 
support for renames seemed more robust than hg's.  I didn't have time to 
try real development with both.

The other rename related thing that appears to happen with hg, that I 
did test myself but have not investigated fully, was that if you rename 
a file, you get another copy in the repository, so if you rename a 10mb 
binary file, you get 20mb in the repo.  With bzr, you get 20mb after the 
rename, but then if you pack or branch from that, it's back to 10mb 
(like it should be).  I'd be interested to know if this is incorrect, 
since I couldn''t see a way to avoid it.

Chris




On 2010/07/20 00:35, Martin Geisler wrote:
> Chris Hecker<checker at d6.com>  writes:
>
>> You may want to read this:
>>
>> http://wiki.bazaar.canonical.com/BzrFileCopies
>>
>> I think it's pretty silly that bzr doesn't support copies, but I do
>> agree with their rationale that renames are more important (at least
>> in my experience), so I think it's slightly sillier that Hg doesn't
>> support renames [...]
>
> Please stop right there! What you say is wrong. Why do you think
> Mercurial does not support renames?
>
> It most certainly does support renaming files, including the "propagate
> change to the new file when merging" scenario. Try a session like this:
>
>    % hg init
>    % touch a.txt
>    % hg add
>    adding a.txt
>    % hg commit -m 'empty a'
>    % hg rename a.txt b.txt
>    % hg commit -m 'rename a to b'
>    % hg update 0
>    1 files updated, 0 files merged, 1 files removed, 0 files unresolved
>    % echo hello world>  a.txt
>    % hg commit -m 'change a'
>    created new head
>    % hg merge
>    merging a.txt and b.txt to b.txt
>    0 files updated, 1 files merged, 0 files removed, 0 files unresolved
>    (branch merge, don't forget to commit)
>
> The 'merging a.txt and b.txt to b.txt' line above tells you that the
> change was propagated into the new name. After a commit the history
> looks like:
>
>    % hg glog
>    @    changeset:   3:4ace64e8504f
>    |\   tag:         tip
>    | |  parent:      2:230b39ecab98
>    | |  parent:      1:4a70576457c4
>    | |  user:        Martin Geisler<mg at aragost.com>
>    | |  date:        Tue Jul 20 09:28:24 2010 +0200
>    | |  summary:     merge changed a into b
>    | |
>    | o  changeset:   2:230b39ecab98
>    | |  parent:      0:c1b55b2a01b0
>    | |  user:        Martin Geisler<mg at aragost.com>
>    | |  date:        Tue Jul 20 09:28:11 2010 +0200
>    | |  summary:     change a
>    | |
>    o |  changeset:   1:4a70576457c4
>    |/   user:        Martin Geisler<mg at aragost.com>
>    |    date:        Tue Jul 20 09:27:59 2010 +0200
>    |    summary:     rename a to b
>    |
>    o  changeset:   0:c1b55b2a01b0
>       user:        Martin Geisler<mg at aragost.com>
>       date:        Tue Jul 20 09:27:45 2010 +0200
>       summary:     empty a
>
> and the directory and file content is as you would expect:
>
>    % ls
>    b.txt
>    % cat b.txt
>    hello world
>