One of the patches recently merged into parsecvs master, namely
commit f5b3cb849517adfd7790c1bfa84bbb84220e3e7b
Author: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Date: Tue Jan 16 04:15:35 2007 -0500
[PATCH] generate tree objects just as we calculate changesets
... and don't store the fsckloads of rev_file in ExportGit mode; they
are only needed (for now) in ExportGraph one.
Tree generation is done directly, without hitting on-disk index. Very fast
now.
broke parsecvs entirely. The reproducer (attached) is very simple:
initial commit of a just added file. parsecvs now barfs on it:
# parsecvs a,v
Initialized empty shared Git repository in .git/
Load: a,v ....................* 1 of 1
Pack pack-6b955e2d966143fc957ccd272e9dd822ceaccf25 created
Removing unused objects 81%...
Removing unused objects 100%...
Done.
error: invalid object d0141680ee5324d51a558a0a48c8a867cbc6a47c
error: writing tree
Authors: No such file or directory
Save: master ....................* 1 of 1
The problem is the following: after that commit parsecvs tries to add
objects to the git tree on its own via calls to libgit; however, in
between it runs git-pack-objects. Thus objects move to pack files
without libgit being aware of it; this results in 'ivalid object'
errors.
However, the object with that hash exists but is stored on the pack
file; if parsecvs is run in the same directory for the second time it
finds it there and happily completes.
I haven't yet had the time to dig deeper into this problem and code a
patch; however, the whole idea of doing part of the job through the
(unpublished) libgit API and the rest via callouts to git utilities
looks like calling for trouble. Wouldn't it be better to teach parsecvs
to speak git-fast-import language instead?
Roman.
head 1.1;
access;
symbols;
locks; strict;
comment @# @;
1.1
date 2007.06.21.12.11.32; author tstuser; state Exp;
branches;
next ;
desc
@@
1.1
log
@test commit
@
text
@this is test
@
