[darcs-users] Re: Fixing a repo with duplicate patches

[Benjamin Franksen]

Tobias Gruetzmacher wrote:
> On Mon, Dec 04, 2006 at 07:47:27AM +0100, Michael Sperber wrote:
>> I have a repository I synch over from CVS via tailor, where tailor
>> generates a duplicate patch name.  How do I fix this?  Just changing
>> the patch names with a text editor seems to generate a repo I
>> subsequently cannot "get".  (I don't have the option of manually
>> hacking the CVS repository.)
> 
> Why do you think the repository is "broken" and needs fixing? Since the
> patch "name" (or "commit message" if you prefer the term other version
> control systems use) is not something that uniquely identifies a patch,
> so there is no problem with multiple patches having the same name. Darcs
> uses a hash over the creation time, the author, the name and the patch
> description to create a unique identifier for a patch. This has some
> potential for collision, but I don't think you hit such a case. Look at
> "darcs changes --xml-output" to see the hash darcs generated for your
> patches. If you have a collision in these hashes, then there is a
> problem, since they would reference the same file for different
> patches...

I am somewhat concerned to hear this. I always thought the hash sum would
also be over the patch _itself_, not only over its meta-data.

AFAIK tailor and other conversion tools like cvs2darcs use the --pipe option
to set time, author, name and patch description to the values found in the
CVS repo. If the CVS repo contains e.g. two separate commits that were done
in rapid succession (e.g. from a script) and using the same (possibly
empty) log message, then time, author, name etc. would all be the same,
possibly resulting in a broken darcs repo.

Not that I think this is the case with the OP's problem, just wanted to
point out that with automatic conversion tools there is a certain positive
chance of such a collision actually happening. Which would be very bad
indeed.

In case this will ever happen to anyone (not me, please), I think the
following procedure would fix the problem: stop the conversion right after
the first of the two supposedly identical patches is converted; then
manually add the other patch with a slightly differing time stamp; then
resume conversion from this point onward. Correct?

Ben