On 06/04/12 21:52, Matthew Dempsky wrote:
> What's considered the current 'best practice' for following OpenBSD
> src with git? I'm interested in trying out git for managing my
> growing list of pending/WIP patches for the src tree, but there seem
> to be a bunch of options and I don't know if there's any preference
> between them.
I'm sharing a git repository with benno@. Since I "don't get" cvs on
some fundamental level - I was the driving force behind this. :)
I was evaluating some conversion tools but they all to varying degrees
are a pain in the ass and weren't generating correct conversions. I
stepped back and threw a lot of stuff out which I thought I don't need:
- HEAD is just fine, I need no cvs branches
- it would be nice to have commit messages in git but that means you
have to somehow simulate changesets which I understand is not (easily,
without heuristics) possible with cvs.
- all the other stuff cvs does which I don't understand (vendor branches
or vendor tags? I don't even know what it's called, etc.)
If I really need cvs commit messages I can search a source-changes@
archive or use cvsweb or cvs.
I set it up by checking out the src tree from a local cvs mirror,
copying all .cvsignore to .gitignore in their respective directories and
adding a .gitignore with only the line
CVS
in it to the top directory:
[florian@openbsd:/opt/git/autosync-cvs/src]$ cat .gitignore
CVS
So src is the cvs checkout and also the directory where .git lives.
You can set it up with .git and the .gitignore with "CVS" in it one
level up, i.e. in the autosync-cvs directory. I don't now if this
changes / improves anything.
We have a cronjob running every two hours (our cvs mirror in /cvs is
updated every two hours as well, I think at even hours and this is
running at odd hours):
[florian@openbsd:~]$ cat bin/update-openbsd-git.sh
#! /bin/sh
cd /opt/git/autosync-cvs/src && ( \
/usr/bin/cvs -q -d /cvs up -Pd
/usr/local/bin/git add .
/usr/local/bin/git commit -a -m 'auto sync with cvs'
)
Re-reading this now I think the "git add ." is not necessary.
This is running since 2011-01-30 without problems. The only time manual
intervention was necessarily was when the error with the (I think)
openssl directory happened which was fixed by removing the files on the
cvs master on the filesystem level. Or something like that. In any case
I had to fix that manually in git.
We were using this setup to develop the netflow v9 / ipfix patch for
pflow on and off for a year with long stretches with no work happening.
So there were merges and rebases involved which worked quite nicely
without problems.
I see that as prove that it works for me.
While writing this down I first thought, wait, this is not correct, we
need to re-generate the .gitignore files from the .cvsignore files
everytime we do an update. Now I'm thinking the initial conversion is
not even necessary. And now I'm confused ;) It's probably only relevant
if you are building a release against a git repo. I think benno@ has
/usr/src sylinked to his repo.
My / our workflow: We are cloning from /opt/git/autosync-cvs/src but
never push anything back. It's only updated by the cronjob. Now we are
in git-land and can work with branches, remote repositories etc.
/cvs and /opt/git are on different hdds which improves speed of the git
from cvs update process considerably. The different git repositories on
the other hand are all on the same filesystem so git can work with
hardlinks.
Once something is done I git diff against origin/master, apply this to a
cvs checkout and call some incantation of cvs diff and send this out.
Since in the end I'm working again with cvs I'm cautiously optimistic
that if the cvs -> git conversion fscks something up or git tracks
something it shouldn't I will catch it in cvs.
So this works for me, I'm not claiming that it will work for anybody
else or that this a good idea.
Florian
--
The distance between genius and insanity is only measured by success.
