-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Haggerty wrote:
> Pete/Piet Delaney wrote:
>> I'm running into a problem with git-cvsimport. [...]
>>
>> I'll take another stab at it tomarrow. Any thoughts or
>> recommendations appreciated.
>
> If this is a one-time conversion (i.e., you don't need to actively track
> a live CVS repository), then I suggest that you try cvs2svn/cvs2git [1].
> It can migrate to git via a git-fast-import output stream [2]. All
> cvsps-based tools necessarily have problems because cvsps (a) doesn't
> output enough information for a reliable conversion and (b) gets
> confused by certain patterns that commonly occur in CVS repository
> histories. cvs2svn can handle every CVS repository that we have seen
> and is also highly configurable [3].
Hi Michael:
I migrated our BLUX build environment from CVS to GIT about six
months ago. In the mean time some additional development occurred
in the CVS repo in a new 'virtualshield_saflow' branch.
In parallel, I updated the git repository and bit keeper repos in
an upgrade from 2.6.12 to 2.6.16 kernel and quite a few of
the associated Linux-From-Scratch (LFS) library migrations.
My 1st resync using git-cvsimport to update the git repo by pulling in
the new 'virtualshield_saflow' branch went without any problems; thought
I recall that it seems more in sync after doing a second cvsimport.
A few weeks later, the second resync came out totally wrong.
This evening I updated the git repo with the corrected files. It
would be interesting to know how it could have been done right in
the first place and to understand why do things like modifying the
imported 'engg' branch that I imported and NEVER should have been
done confused git. I suspect that doing:
git-cvsimport -o virtualshield_saflow -r origin blux
wasn't right I don't think I has to use "-r origin' option on the
1st import of the 'virtualshield_saflow' branch.
Hopefully we are done with the CVS repo updates. If it turns out
that it all should be done again, avoiding the modification of
imported branches, we'll look at using the cvs2git approach that
your recommending.
How does your proposed cvs2git facility deal with importing on top
of branches that have been modified?
>
> Michael
>
> [1] http://cvs2svn.tigris.org/
> [2] http://cvs2svn.tigris.org/cvs2git.html
> [3] http://cvs2svn.tigris.org/features.html
Thanks for to pointers.
- -piet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIq8lDJICwm/rv3hoRAut5AJ4qLkfBBym9aC7Aajae8VkkrxE58gCffb5S
I5g8ri5ZLPUQ7uL7h/Kx2/M=
=RF1O
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
