Date: Sat, 25 Jun 2005 23:35:29 +0200
From: Axel Brandenburg 
To: Wolfgang Dobler 
Cc: Tony Mee , Tobias Heinemann ,
        Anders Johansen 
Subject: Re: dobler committed "f90/pencil-code/perl Namelist.pm"

First, I verified that the eos branch compiles and runs also with the ifc 6.0
compiler.

Second, after a preliminary discussion with Tony earlier today 2 discussed
the following 2 alternatives:

1) the "main trunk alternative":
   --> merge the eos branch with the main one like: "cvs up -kk -j eos"

   graphically this means   ------------x------
                              ---------/

2) the "eos alternative":
   --> merge the latest changes from main trunk into eos,
   (easier than former alternative because Tony kept eos branch reasonably
   up to date with changes on the main trunk).
   --> copy all files into an earlier checked out version of main trunk,
   merge (if there have been changes on main trunk) and check in.

   graphically this means   ------------x---x------
                              -----------\-/

As far as the line-by-line information in cvs annotate is concerned, both
options have the same properties, as far as I can see:
   -) all the changes that have ever happened on the eos branch will be
      associated with the user who is doing the final check in into the
      main trunk.
   -) this is unavoidable (I think) and quite unfortunate
   -) all the annotate information from the main trunk will be preserved.
   -) the reduced information content regarding eos on the later main trunk
      should be highlighted in a obvious way (e.g. by performing the final
      checkin of the merged version under a new cvs user (eg eos_user1, 2, etc)
What do you think? Any other alternatives?
Axel

Date: Sat, 25 Jun 2005 18:49:29 -0600
From: Wolfgang Dobler 
To: Axel Brandenburg 
Cc: Tony Mee ,
        Tobias Heinemann ,
        Anders Johansen 
Subject: Re: merging

I thought that variant 1) would preserve the log messages and user info of
the changes that are merged in, but now that I think about it, this seems
to be somethig that only advanced revision control systems like Darcs can
do, not CVS.

Given this, variant 2) seems to be preferrable.

It might be worth googling for tools that extract the changes one by one
from the branch and merge them with the same log message into the trunk --
this is certainly doable, but writing such a tool ourselves would take far
too much time.

W o l f g a n g

Date: Sun, 26 Jun 2005 08:09:40 +0200
From: Axel Brandenburg 
To: Wolfgang Dobler 
Cc: Tony Mee , Tobias Heinemann ,
        Anders Johansen 
Subject: Re: merging
In-Reply-To: <20050626052522.GA8832@ns1.nordita.dk>
User-Agent: Mutt/1.4.1i
  
>                                   (1)       (2)
> >  >    graphically this means   --X---------x---x------
> >  >                               -----------\-/
>                                              (3)
>
> (1): trunk_fixed_eos (tagged around 21 Oct 2004)
> (2): trunk_fixed_eos2 (tagged yesterday evening, before Sven checked in
+something)
> (3): eos_before_merge_trunk_fix

I forgot to mention one issue. Since tag trunk_fixed_eos2 was produced
before Sven checked in his change, and if all of us (not just Mee and me)
had checked out version (2), then Sven's change will be preserved after
us copying (3) onto the main trunk (provided we don't update beforehand,
of course). We can always emulate this by cvs up -r trunk_fixed_eos2,
then saving the relevant file (in this case boundcond.f90) in an save directory,
then cvs up -A, copying save/boundcond.f90 over, and changing in CVS/Entries
   /boundcond.f90/1.74/Sun Jun 26 06:01:39 2005//
to
   /boundcond.f90/1.73/Sun Jun 26 06:01:39 2005//

CVS doesn't seem to look at the date, only at the 1.73.
Axel