Re: Feedback on using cvs2bzr

Max Bowsher пишет:
> 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.

Yes.

For bzr project in the past I wrote special support in setup.py to create batch wrapper at install
time. If you wish I can help to port this solution to your setup.py.

> I guess we should FAQ this.
[...]
>> 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 :-/

I'm Python programmer and I can help to debug/fix this if you can guide me.
Although I'm not CVS/CVSNT expert. In the past I've heavily used TortoiseCVS as my main GUI client,
then I've switched to bzr. But my knowledge of CVS CLI is very poor.

>> 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.

OK, make sense. I've not studied very carefully original history for such things.

> 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.

Thanks.

Alexander

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

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