Re: Feedback on using cvs2bzr

Alexander Belchenko wrote:
> I've just successfully converted CVS repo hosted on sf.net to Bazaar 
> format and I'd like to provide some feedback about this process.

Thanks!

Summary point 3): Extensionless scripts don't work on Windows.

I guess we should FAQ this.


Summary point 5): "cvs2bzr --dumpfile out.fi repo" crashes with
AttributeError: Values instance has no attribute 'blobfile'

Yup. Definitely a bug.


> 6) At this point I've decided to look at using options file. The options 
> example is overwhelmingly big. This is maybe useful for experts but for 
> me as casual user of cvs2bzr it was too much.

I tend to agree that the options files are a bit scary/huge.


> Unfortunately I've discovered that resulting dump file has no texts for 
> all files at all. And after importing this dumpfile to bzr format I've 
> got correct revision history but all files has zero length.
> 
> As I discovered later the problem was in CVSNT executable which is used 
> by TortoiseCVS installed on my computer:
> 
> C:\>cvs version
> Concurrent Versions System (CVSNT) 2.5.03 (Scorpio) Build 2382 
> (client/server)

This sucks. Though I have to admit, my plate is sufficiently full with
non-Windows stuff that I'm unlikely to ever do anything about this
particular issue myself :-/



> 10) But I want to point to another issue with conversion: during/after 
> conversion cvs2bzr has created several dummy revisions to attach tags to 
> them. In bzr tags are very similar to tags in CVS and does not required 
> special commit. They should not clutter the main history. I suppose it's 
> svn-centric point of view and it leaked into this conversion. I'd say 
> it's a bug, because neither bzr not git (IIRC) does not required special 
> commit for tags.

Ah, no, no bug. These are 'fixup' commits - created only when a CVS tag
corresponds to no single revision at all. In git/bzr/hg, tags point at
complete revisions. In CVS they point at any arbitrary selection of
files at potentially unrelated points in history. Hence synthentic
changesets are required to resolve this disparity.

I have some thoughts about changing how this works, specifically:

* only giving these fixups one parent, the state to which they most
closely correspond, rather than recording them as merges from every
contributing changeset.

* writing some sort of report of the mixture to their log message

* fake-merging these changesets back into the line of history they
branched from immediately after their creation, in order to prevent an
explosion of tag-fixup branches in the resulting output - which for bzr
in particular should make for a friendlier conversion result.

These ideas are not quite fully implemented, but I do intend to try to
commit some parts of them soonish.


Max.

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2411388

To unsubscribe from this discussion, e-mail: [[email protected]].

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrlqaEACgkQfFNSmcDyxYAK2QCcCSL1LTTD3nMm5zN2IOJVztZC
jgMAoNt1KUy3pc5nfkuELpY/1sGumiZD
=ZlWX
-----END PGP SIGNATURE-----