transpant and keywords together

Berkes Adam adam.berkes at
Tue Dec 22 01:27:08 CST 2009

The problem is indeed that the problem is that keywords are transplanted 
as *expanded* to target branch, and that will became part of the 
repository which causes weird modified status with empty diff (if 
keyword extension is turned on).
E.g.: if I modify a file keyword will be correctly handled during commit 
so '$Id$' will be written back to repository (checked by turning off 
keyword extension) but if keyword extension is turned on and I would 
like to transplant this change to another branch then the transplant 
process will use the expanded form ($Id: 25696 someuser...$) from the 
working copy and that will be committed.

@Matt: for me it is totally clear that using keywords is a kind of 
deprecated way and should be avoided, but I was unable to convince other 
parties in our project. That is the case now.


> * Berkes Adam on Monday, December 21, 2009 at 14:21:46 +0100
>> I have a problem with transplant extension when keyword extension is
>> also active. When a changeset contains a file which has an
>> expandable keyword transplant is going to apply the file to the
>> destination branch as keyword is in expanded state (the source
>> changeset is correct, repository contains the shrinked version).
> I've read your description several times, unfortunately I don't
> understand it ;-(
> Is the keyword in the destination branch expanded or not?
> Simple example starting with 0 revs:
> $ hg transplant -s ../test -p 1:tip
> changeset:   0:87cf64da941f
> user:        Christian Ebert<blacktrash at>
> date:        Sat Nov 24 12:41:01 2007 +0100
> summary:     addA
> apply changeset? [ynmpcq?]: y
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> added 1 changesets with 1 changes to 1 files
> $ cat a
> $Id: a,v 87cf64da941f 2007-11-24 12:41 +0100 blacktrash $
> hello
> $ hg id
> 87cf64da941f tip
>> I've saw forum post about the subject which was rather old, so I'm
>> not sure it is a forgotten one or simply it never raised as a
>> problem?
> Do you have a link?
>> I can reproduce it with 1.3.1/1.4.1 as well.
> Can you provide a small sample script to show the problem?
> c

More information about the Mercurial-devel mailing list