transpant and keywords together

[Berkes Adam]

It is 100% reproducable, I've tried a small scenario:

   1. turned on keyword extension in ~/.hgrc
   2. hg update null
   3. hg update -r xxx /* $Id$ correctly expanded, I had checked)
   4. Do a change on a file with $Id$, commit the change (keywords updated)
   5. hg push /* I have a clone and a second clone from it for branch */
   6. cd ../main /* change to other clone */
   7. hg update null
   8. hg update -r default
   9. hg -y transplant --config extensions.hgext.transplant= --log
      --branch xxx 7ea8b487db0c8ae761435115a48e11d7198c9592
  10. hg status shows difference for the changed file on keywords part
  11. turned off keyword extension in ~/.hgrc
  12. hg update null
  13. hg update -r default /* $Id: ...$ is in expanded form for the
      transplanted file, others contain shrinked version */

Adam
> * Berkes Adam on Tuesday, December 22, 2009 at 08:27:08 +0100
>    
>> 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.
>>      
> $ pwd
> test-nokw
> $ hg transplant -s ../test -p 1:tip
> changeset:   0:87cf64da941f
> user:        Christian Ebert<blacktrash at gmx.net>
> 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$
>
> hello
> $ cd ../test
> $ hg cat -r 0 a
> $Id: a,v 87cf64da941f 2007-11-24 12:41 +0100 blacktrash $
>
> hello
>
>
> It doesn't look like the keyword is transplanted in expanded
> form.
>
> In case you switch keywords on and off inside the same repo, you
> have to run "hg kwshrink" *before* turning off keyword expansion,
> as "hg help keyword" says:
>
> #v+
> Before changing/disabling active keywords, run "hg kwshrink" to
> avoid the risk of inadvertently storing expanded keywords in the
> change history.
>
> To force expansion after enabling it, or a configuration change,
> run "hg kwexpand".
> #v-
>
> I probably misunderstand something, so you could help me by
> providing an example, preferably simple for my simple mind ;-)
> where it fails.
>
>    
>> @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.
>>
>> @Christian: http://www.selenic.com/pipermail/mercurial/2008-May/019269.html
>>      
> Yes. Since then I continuously run a conversion of the vim7 CVS
> repo, with hg keywords enabled (i.e. converting CVS keywords into
> hg keywords), also continuously merging rsynced runtime files
> without any keyword troubles.
>
> I asked for an example that I could reproduce in
> http://www.selenic.com/pipermail/mercurial/2008-May/019280.html
> and got no response.
>
> c
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20091222/c31872e9/attachment.html>