Re: [Gnucap-devel] gnucap development snapshot 2013-04-23

[al davis]

On Thursday 25 April 2013, Felix Salfelder wrote:
> it's all about rebasing the history of gnucap-uf which i need
> to do somehow. that would be much easier without the
> directory breakage.

Ah ..  Now you know why I put off the migration to Git, and kept 
it in RCS for so long.

On Thursday 25 April 2013, Bas Gieltjes wrote:
> I know that there is no definitive choice made for a new
> revision control system,

Git seems to be the choice.  Can anyone give me a real reason 
for any other choice?

> but it is possible to move the RCS
> file history to git. A search gives several methods to move
> data from RCS to a new revision control, if the old commit
> history is important...

I know there are ways to do it.

The question ..  should it be migrated?

To trace back to zero, over lots of changes, eventually it can 
look like a big mess, so I think this is a place to make a 
break.

Looking back, I was surprised at how many non-traceable changes 
there are.  Files are split.  Files merge.  When they do that, 
what names to use?

At one point, I did a trial switchover to CVS (unpublished).  
CVS is almost the same as RCS, so I thought it would be 
transparent.  It wasn't.  CVS has a slightly different way of 
numbering that was incompatible with the way I used version 
numbers, which meant that checkouts were inconsistent.  So, I 
kept it in RCS.  Another way to use the tags in RCS would have 
worked, but not the way I did it, and what was done was done.

I think the same issues would come up with any migration.  
Subtle differences would screw things up.  So I think it is best 
to keep the old stuff in RCS, now frozen, for the rare case when 
somebody might actually want that old version.

Really long ago ... long before the transition from C to C++ ..  
was the transition from Ratfor to C.  You really don't want to 
see the code that far back.

On Thursday 25 April 2013, Bas Gieltjes wrote:
> The
> (essential?) commit messages are missing and some commits
> contain a list of n's, no clue why those n's are  included.

I didn't use the RCS commit messages, but rather mostly made 
commits in sync with development snapshots, with release notes 
having  that info, often a whole page of it.  I didn't see the 
value of the one-liners that RCS supported.

Whether this was a good idea or not is irrelevant now.