Re: [Gnu-arch-users] gnuarch 1.2.1 released! (reannouncement)

[Colin Walters]

On Mon, 2004-08-16 at 05:46 -0400, James Blackwell wrote:

> Only if Tom fixed it. I took Tom's base-0 - patch-28 without any sort of
> review.

As far as I know it has not been fixed.

> For the lazy, the bug reads thusly: 
> 
> ] I have a project that uses taglines, and one of the taglines contains
> ] the " character.  Before pika escaping, this character was stored
> ] literally everywhere.  With pika escaping, it is stored in changesets as
> ] \". This obviously breaks compatibility with older versions of tla, and
> ] can cause silent corruption.
> ] 
> ] Why are we escaping file ids at all?
>  
> I haven't verified that this bug exists (by chance, did you?).
> 
> However, I'm willing to bet that cehteh and Tom would have done
> something like this because the other tagging methods store files on
> disk.

I guess one reason to escape would be to allow non-ASCII characters in
taglines.

> > This seems to me to be a very critical bug since it breaks backwards
> > compatibility and will easily lead to corrupted archives.
> 
> Can you walk me through how the bug causes corruption, I'd think that
> the worst we'd end up with is an otherwise unnecessary file delete/add

It's pretty simple.  tla 1.2.1, when creating a changeset, quotes the "
characters in taglines.  Older clients downloading this changeset do not
unquote it, and so to them, it appears to be a missing patch, and thus
gets put in +missing-patches (note this doesn't even appear as an
error).  The older client thus sees an inconsistent tree.  If they do
further work on the file and then commit, new clients will get a
conflict.

Robert was suggesting a changeset version number, so old clients would
just error out when they saw new changesets.

However we're in a double pit now because tla 1.2.1 has already been
released without the version numbering.  So we'll need to support tla <
1.2.1, tla 1.2.1, and tla > 1.2.1.