[Gnu-arch-users] Semi-severe bug in tla-cygwin 1.2.1-dirnames

[John Meinel]

I've been using tla 1.2.1 with dirnames support now, pretty much since 
it came out. And there are 2 problems I've been running into, both 
pretty annoying.

First, the original tar extraction doesn't seem to be path-compressing 
the files. So it now will fail if there are old patch-logs with long 
pathnames in them.

Now, it does the correct thing in the filesystem once it is checked out, 
but doing a 'tla changes' fails. (I'm using a revlib which might be the 
cause.)

The second is more severe because it seems to cause invalid patches to 
be added to the repository.

I ran into it once in the past, but thought it was a fluke, but this is 
the second time.

As near as I can tell, the current diff is doing weird things when 
facing files with CR/LF versus just plain CR. I personally try to keep 
all of my files with CR only, but since I'm on windows every so often 
one slips through.

If you have a file with CR/LF, and you modify it, the diff seems to 
think that the old version only had CR, and suddenly you changed every 
line to CR/LF.

Now this causes conflicts when trying to check out the tree, because the 
last revision doesn't match what the patch says it should be.

I just had a conflict on a file. And then I went back and ran "dos2unix" 
on the file, and now it doesn't seem to think there are any differences 
in the file. I'm guessing whatever patch you are using is opening the 
file in 'r' mode instead of 'rb', so when it reads it gets the file 
endings converted for it. But I'm not positive.

So for now, I'm just going to go back to 1.2-dirnames, nuke my revision 
library, and hobble forward.


Though in all honesty, if you (Lode) are to work on anything, I think I 
would rather you get the dos8.3 branch working. It should perform 
better, and be less of a headache.

Of course, the best is if we can get the {arch} directory to use c/b/v 
instead of c/c--b/c--b--v/

John
=:->

signature.asc
Description: OpenPGP digital signature