Re: [Quilt-dev] Backward compatibility of quilt's pc directory

[Andreas Gruenbacher]

Hello,

On Thu, 2004-05-27 at 20:19, Martin Quinson wrote:
> Hello,
> 
> Recent changes in quilt broke the backward compatibility of the openned
> tree. Specificaly, the pc directory of trees created with versions <=0.30
> are not readable with versions >=0.32 (if I understood correctly). This
> makes working trees unusable on system update.

Not sure when the incompatible change happened, but there definitely was
one. I don't think it's interesting to research when that was exactly.

> I see this lack of backward compatibility as a major show stopper for the
> future of the project. If this is not solved, it is impossible to package it
> properly as I tryied to do for the Debian project.
> 
> Indeed, it will require the users to pop all quilt trees before updating
> their machine. Moreover, in the case the administrator and the user are two
> different persons, this is even more problematic.
> 
> If you think that no further change to the internal layout will ever happen,
> I guess we can live with that, and suffer the angry of the users.

It may well be that there will be future changes in the on-disk format.
It is likely too late to introduce versioning for the current format as
we cannot easily tell the different formats from each other at the
moment. We can introduce versioning when the next incompatible change
becomes necessary. Depending on how big that change will be, we can
either convert the on-disk format, or reject the meta-data.

We could add some heuristics to detect old meta-data formats. I would
probably be able to find out what changed exactly without taking too
much time, so we could in theory add version numbers to existing trees.
I don't think this would be worth it, though.

> If other changes may happen in the future, the minimal solution would be to
> add a 'quilt_version' file in the pc dir, so that the problem can be at
> least correctly diagnosticed, and proper error messages produced.
> 
> A better solution would be to keep older 'refresh' and 'pop' tools  so that
> it becomes to pop a tree (but not to work on it) even after a system upgrade.
> 
> Of course a yet better solution would be to come up with a layout converter
> tool which would not need to pop the tree completely and start a new one.

I would prefer a proper conversion. Keeping old versions of the tools
around would cause a lot of pain; the scripts depend on each other.

> Andreas, you are by far the main developer out here (shame on me for not
> helping more), so the decision about which solution to take is yours.

Because of what I have said above, I would pefer to do nothing at the
moment. I am meanwhile convinced about the usefulness of versioning, so
the next change in the meta-data format would be the right time to also
add this. Do you agree?

Cheers,
-- 
Andreas Gruenbacher <address@hidden>
SUSE Labs, SUSE LINUX AG