[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: willing to contribute verrevcmp to gnulib?

From: Ian Jackson
Subject: Re: willing to contribute verrevcmp to gnulib?
Date: Tue, 30 Sep 2008 11:13:08 +0100

Kamil Dudka writes ("Re: willing to contribute verrevcmp to gnulib?"):
> we use the extended version (handling ~ character), even slightly
> modified to work better with file names (with suffixes). The new
> (gnulib) filevercmp code is in attachment.

Sorry, I overlooked this message before.  Now I'm really confused.
You seem to have already rewritten it.  So why are people asking for
permission and/or copyright assignment ?

I haven't reviewed your implementation for correctness but I will if
you want me to.  Did you base your version on the Debian specification

> /*
> TODO: copyright?

Who actually wrote that code ?

Actually, looking at it it seems to have been created by copying and
pasting Anthony Towns's verrevcmp and reformatting it !

This is surely a ridiculous approach.  What if it needs to be extended
or modified in the future ?  You won't be able to just apply patches
from dpkg.  Reformatting code just for the sake of it is always wrong.

NB that this is a technical objection.  I'm sure that Anthony Towns,
just like any member of the Free Software world, would not try to use
copyright law to prevent someone from making stupid modifications to
their code.

On to a more useful conversation:

Can you explain in some more detail why you took the approach that you
did for file extensions ?  I'm not sure I understand the specific
effect.  Is it exactly equivalent to adjusting the lexical value of
the rightmost `.' in each string to be just greater than `~' ?

What about filenames like
  alice_1.63.orig.tar.gz        or      linux-
  alice_1.63-2.dsc                      linux-
  alice_1.63-2.diff.gz                  linux-

If you were to just compare whole filenames you get:
  alice_1.63-2.diff.gz          and     linux-
  alice_1.63-2.dsc                      linux-
  alice_1.63.orig.tar.gz                linux-
which is for alice perhaps not ideal but your algorithm does this
  alice_1.63-2.diff .gz         and     linux- .bz2
  alice_1.63-2 .dsc                     linux- .gz2
  alice_1.63.orig.tar .gz               linux- .sign
                                        linux- .sign
which is just bizarre (spaces put in to show the cut point)
and in the RHS leads to odd results.

So I think this wrinkle may be doing more harm than good.  We might be
better off with a simpler algorithm.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]