Re: Access to CVS

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2012-12-05 at 01:33 +0100, Oliver Kiddle wrote:
> Phil Pennock wrote:
> > (zsh is about the only thing I still use CVS for; FWIW, if folks do ever
> >  decide to switch, I don't much care which DVCS is chosen (git, hg,
> >  whatever) but would appreciate such a switch.  Any hope of the git
> >  mirror becoming the official master repo?)
> 
> I gather that the current status is that we just need a git expert
> willing to take the lead on that.
> 
> There's also a couple of things that need sorting out:
> 
> Associating commits to mailing list numbers. This amounts to using git
> notes (see workers/30123) so probably just needs a clear convention.
> Perhaps we could use a hook script to enforce it on the master 
> repository.

Biggest problem is if the change in the mail doesn't exactly match the
files being patched, in which case there's not identifying information
in the mail to figure out the commit.  If the person grabbing the patch
uses "git note" manually, or as a filter to grab X-Seq, then it works.

*If* the patch in the mail is cleanly applying to the exact same files,
then you can use a cron job, taking recent mails from zsh-workers, so
that there's as much decoupling as possible, and zsh-workers vs
git-commit ordering doesn't matter.

Taking a git patch from an email and turning it into full blobs of the
new version of a file (ie, the id of the new content):

 cat mail-file | \
 pcregrep -o1 -M '^index\s+[0-9A-Fa-f]+\.\.([0-9A-Fa-f]{6,})\s\d+\r?\n--- a/' \
 | git cat-file --batch-check

Output is lines of "${checksum-id} blob ${blobsize}"

Use with:
  https://github.com/jwiegley/git-scripts/blob/master/git-find-blob
and find the earliest commit id where a tree referenced the blobs from
the mail.

It's horrendously inefficient, but if you're constraining it to
--since="5 days ago" to allow for maximum discrepancy, then you've
bounded the O(N^2) to very small values of N.

Scenario 1 (rarer):
 * commit, then mail out the patch to say "er, I did this"
   * mail is processed, finds the commit, you have five days to get
     around to mailing

Scenario 2:
 * mail out, then commit.  The mail is held until successfully matched.
   Once the commit is made, the mail is deleted.  The cronjob presumably
   runs every hour or so, thus --since="5 days ago" is about 4days23hrs
   generous

Scenario 3:
 * no git diffs in the mail; log that nothing found for that X-Seq:,
   delete

Ickiest bit is the reporting for mails older than a week which haven't
been matched, and the commits without the note.  That requires HTML
skills to make the pretty web-page people want when tracking down what
got lost.  ;)

> Generating the patch level some other way. Using the git hash (or

There's what we do in Exim:
  http://git.exim.org/exim.git/blob/HEAD:/src/scripts/reversion
around line 40.


I can't commit time for a _project_ to complete any of this until some
time next year.  Sorry.  :(  Folks are still waiting on revamped
regex/multibyte-counting fixes from me.  :(

-Phil