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

[John Meinel]

address@hidden wrote:
> John,
>
>
> > 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.
>
>
> I fixed the first problem: while upgrading tar, and applying the 
> pathcompress-patch
> manually, I missed the mkdir's... I need to annotate
> each mkdir by 3 calls, and only added 1. This only affects the =dirnames
> version, which I didn't test enough. Should be fixed now.

Good to hear.

> > 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.
>
>
> As you know, tom (and thus tla) is single-minded: there is only unix.
> tla does not handle the CR/LF problem /AT ALL/.
> I'll see if diff can be changed to ignore the CR/LF... but in the end,
> this is a fundamental limitation in tla... when I first looked at tla,
> I mentionned this on the list, and the answer was to go configure
> my tools properly... in the ever so friendly style of the lord...

Well, I actually prefer the way tla does it. Where a file is a file, and 
it doesn't try to change it. Pretty much all of my editors support 
either format, (I use gvim, SciTE, and msvc on Win32)

The problem that caused the collision is that the diff you were using 
would generate a .patch file, such that the '-' side did not have CR/LF, 
but the '+' side would. So when patch comes along the '-' side doesn't 
match, and you get a conflict.

So really, I think if you just open the files in 'rb' and 'wb' mode, 
things would work fine.

Also, remember that if you are using pipes to send stuff through the 
different programs, there is something weird with cygwin. I don't 
remember exactly, but I think it always opens a pipe in non-binary form 
(translate CR/LF -> CR). So if you were doing:

cat oldfile.txt | diff - newfile.txt > newfile.txt.patch

I think it would do the wrong thing.

> > 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.
>
>
> tla-dos8.3 should work fine now: I created an archive locally, and pushed it to
> be mirrorred on a linux box over SFTP. works like a breaze. you should
> try it out, really.

I will certainly do so. I am very interested in this branch.

> > 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
> > =:->

John
=:->

signature.asc
Description: OpenPGP digital signature