Hi David,
Thanks for the detailed instructions. It does happen that we're using
Phone::Number::UK, though I'm pretty sure it's not in the actual
repository. My first attempt was with 'git cvsimport', but it failed.
However it didn't give me much useful information about what it didn't
like. How did you find the offending file?
I'm very anxious to get the cvs import to work, because otherwise I
can't s/cvs/git/ without some serious workarounds. I even tried going
git _within_ my cvs working directory. Technically it worked, but it
felt very cumbersome and error prone so I quit trying. I'll have to
give this a try tonight...
Drew
On 6 Mar 2009, at 13:18, David Cantrell wrote:
On Fri, Mar 06, 2009 at 09:36:25AM +0000, Drew Taylor wrote:
I've been trying to figure out how to worm git into our workflow at
$work where we currently are using CVS. I tried to import the CVS
repo
to git a couple different ways but was spectacularly unsuccessful
both
times.
I've just taken my CVS repo from sourceforget and imported it into git
just fine. The recipe was:
Get a local copy of the entire repo:
$ rsync -av rsync://drhyde.cvs.sourceforge.net/cvsroot/drhyde/
$HOME/cvs-repo
Build and install cvsps, which you can get from here if your OS
doesn't
have a pre-built package of it. You need version 2.1 or higher (2.1
is
the most recent stable release):
http://www.cobite.com/cvsps/cvsps-2.1.tar.gz
Import. This may take a Very Long Time, and needs absolute paths:
$ git cvsimport -av -d $HOME/cvs-repo -C /path/to/new/git-repo cvs-
module-name
I found that cvsimport didn't like this file in my CVS repo.
http://drhyde.cvs.sourceforge.net/viewvc/drhyde/perlmodules/Number-Phone/lib/Number/Phone/UK/Data.pm?view=log
It's a huge binary, with several *very* large changes in its
history, so
I'm not surprised as it's egregious CVS-abuse. It probably ran into
my
ulimit settings. I couldn't be bothered to investigate though, and
just
removed it from the repo by hand, and then added the most recent
version
of the file into the newly created git repo afterwards, thus losing
its
history:
I also found that after cvsimport had died and I'd removed the
offending
file from the CVS repo (don't forget to remove the history log as
well!),
I then had to delete the newly created git repo and start the import
again - it didn't like continuiing where it had left off, despite the
doco I was following indicating that that should work.
Finally, once the import has succeeded, prepare it for access by
multiple users and clean up so you're not tempted to work in the git
checkout you just created - you probably want to treat it as a
traditional CVS repo:
$ cd /path/to/new/git-repo
[delete everything in this dir apart from the .git directory]
$ mv .git repo.git
$ sudo chgrp -R gitusers repo.git
$ find repo.git -mindepth 1 -type d |xargs chmod ug+rwx,g+s
$ GIT_DIR=repo.git git repo-config core.sharedrepository true
You can then checkout thus:
$ git clone /path/to/new/git-repo/repo.git working-copy/
or over ssh:
$ git clone hostname:/path....
You update your working copy thus:
$ git pull
Remember that 'git commit' in your checkout only checks in locally, to
"commit" to the server:
$ git push
All of that seems to Work For Me and I can fiddle with my code on
either
my laptop or my desktop and it behaves just like CVS. I'd do some
rather more rigourous testing with multiple concurrent users doing
updates before relying on it though!
git++ # CVS with offline commits
--
David Cantrell | London Perl Mongers Deputy Chief Heretic
What profiteth a man, if he win a flame war, yet lose his cool?
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
