questions on development(7)

[Simon 'corecode' Schubert]

Giorgos Keramidas wrote:
>>> I'm only tracking 'HEAD' most of the time, but there are some efforts
>>> underway to convert the history of src/.  One notable example is the
>>> effort to convert to Subversion first, and then use the tags/branches
>>> and changesets of Subversion to populate an Hg tree.
>> That seems wrong.  A conversion to subversion means losing precision
>> and time.
> Can you elaborate a bit.  I am not sure I got why you lose precision.

This is due to the fact that CVS doesn't have changesets.  It is too
late now and it is also quite complicated to explain, but it boils down
to the fact that aggregating changesets will remove information, namely
the single file revisions, which you could use for a direct conversion
to hg/git.

>>>> Also cvs20hg doesn't appear to grok Hg branches (probably because it
>>>> predates them) and it would be Really Nice(tm) if it did.
>> cvs20hg is deprecated since two years or so.
> I know that.  It's just that fromcvs doesn't quite work for me here,
> yet, so I had to stick with a patched cvs20hg version.

I am surprised that cvs20hg works better.  Fromcvs allows you to ignore
certain branches, maybe that's what you need?

>> Please try fromcvs instead.  There are some bugs left, of course.
>> Last thing it seems I introduced some memory overflow problem, so that
>> a conversion of src now runs out of memory (on a 32bit machine).  Up
>> to a couple of months ago this was running very smoothly, see [1].
> 
> Something is missing for [1], I guess :)

yes, sorry.

[1] http://www.theshell.com/cgi-bin/gitweb.cgi/

> I tried fromcvs to the doc/ tree (non-branched, less repo-surgery
> "magic" to handle), but it stops with a traceback very soon:
> 
> % $ pwd
> % /home/keramida/hg/fromcvs/fromcvs
> % $ ruby tohg.rb /home/ncvs doc ~/tmp/foo
> % [...]
> % /home/ncvs/doc/bn_BD.ISO10646-1/articles/new-users
> % /home/ncvs/doc/bn_BD.ISO10646-1/articles/explaining-bsd
> % /home/ncvs/doc/FAQ/Attic
> % upgrading roberto to 1/ (1.1.1)
> % Traceback (most recent call last):
> %   File "./tohg.py", line 102, in <module>
> %     destrepo.dispatch()
> %   File "./tohg.py", line 98, in dispatch
> %     func(*l[1:])
> %   File "./tohg.py", line 78, in cmd_commit
> %     extra = {'branch': branch})
> % TypeError: commit() got an unexpected keyword argument 'wlock'
> % tohg.rb:200:in `readline': end of file reached while handling set [doc/handbook/Attic/troubleshooting.sgml,v:1.1.1.1,doc/handbook/Attic/sup.sgml,v:1.1.1.1,doc/handbook/Attic/slips.sgml,v:1.1.1.1,doc/handbook/Attic/slipc.sgml,v:1.1.1.1,doc/handbook/Attic/scsi.sgml,v:1.1.1.1,doc/handbook/Attic/ppp.sgml,v:1.1.1.1,doc/handbook/Attic/ports.sgml,v:1.1.1.1,doc/handbook/Attic/porting.sgml,v:1.1.1.1,doc/handbook/Attic/nfs.sgml,v:1.1.1.1,doc/handbook/Attic/submitters.sgml,v:1.1.1.1,doc/handbook/Attic/kerberos.sgml,v:1.1.1.1,doc/handbook/Attic/handbook.sgml,v:1.1.1.1,doc/handbook/Attic/glossary.sgml,v:1.1.1.1,doc/handbook/Attic/diskless.sgml,v:1.1.1.1,doc/handbook/Attic/dialup.sgml,v:1.1.1.1,doc/handbook/Attic/eresources.sgml,v:1.1.1.1,doc/handbook/Attic/current.sgml,v:1.1.1.1,doc/handbook/Attic/ctm.sgml,v:1.1.1.1,doc/handbook/Attic/basics.sgml,v:1.1.1.1,doc/handbook/Attic/authors.sgml,v:1.1.1.1,doc/handbook/Attic/bibliography.sgml,v:1.1.1.1] (EOFError)
> %         from tohg.rb:200:in `_commit'
> %         from tohg.rb:122:in `create_branch'
> %         from ./fromcvs.rb:989:in `commit_sets'
> %         from tohg.rb:228
> % $
> 
> I don't know how to read Ruby code, so I can't fix this myself, but any
> ideas/help/patches you have I can test easily :)

This is because mercurial changes its API on every release.  Somebody
who is using hg and fromcvs needs to update the code.  I got tired of this.

>> I suppose you know about fromcvs.  I also guess you know that I
>> suggest using git instead of hg.  Doesn't produce nasty large index
>> files either :)
> I wasn't aware that you strongly prefer Git.  Any references I can read,
> so find out more about why you do?

Sorry, I didn't write up the reasons.  It's more of a personal feeling
and a preference for the git repository layout.  This layout allows many
things to be implemented in a very simple way (ref. branches).  Also, it
is better suited to have multiple branches in a repo, which is usually
what you want to do if you're syncing with multiple persons.  Hg only
has heads.

cheers
  simon