Re: [Gnu-arch-users] Using win32 and unix questions

[John A Meinel]

Neilen Marais wrote:

> Hi!
>
> I'm working on an academic code, and have been using tla quite happly as
> a simple revisioning system under linux. I told my colleauges who will
> be colaborating with me about arch, and they were quite interested!
>
> The problem is that they are using windows, and I Linux. Also, I don't
> use windows at all, so it's hard for me to test out the various windows
> releases.
>
> > From what I can tell from the wiki, there are 3 win32 tla ports. The simplest
> to use seems to be the Johannes port, but it does not seem to do any
> path-name compression. How likely is one to run into trouble, and what
> causes it? i.o.w., will it help to keep the archive low in the directory
> tree (e.g. c:\arch\blah instead of c:\somedir\anotherdir\projects
> \...\blah)?
Starting lower in the directory tree will help. But only a little. The
bigger help is to keep your archive, category, and branch names fairly
short. (address@hidden/tla--devo--1.3 checks out fine, but
address@hidden/gui-pulmonary-workstation--gui-cleanup--0.1
is likely to fail.)

If you have cygwin installed, I've worked on 2 different versions. I
updated Lode's dos dirname version a little bit, and have a binary
release available at:
http://ct.radiology.uiowa.edu/~jfmeinel/tla-short-path/testing/

The branch is at
http://ct.radiology.uiowa.edu/~jfmeinel/archives/address@hidden
you would checkout
address@hidden/dists--pcomp--1.3.1

I should probably update this for the new tla 1.3.2 release...

This does compression by using the 8.3 dos name for each directory path.
Which means that it will checkout just about anything, though you can no
longer use Explorer to delete your directories (explorer doesn't handle
NTFS long pathnames).

Alternatively, there is my old tla-short-path version, which is
available in the same general area. It actually removes the redundancies
in path names, so that the created paths aren't as long. However, it can
still fail if your names are too long.

If you don't want cygwin, Johannes' port is the only one that runs
natively. I wasn't able to get it to work on my machine. (To be fair,
Johannes has difficulty running mine on his machine :).

> As for the unix/dos line endings, I assume that won't be a problem if
> the development environments are line-ending agnostic. The windows guys
> are using Compaq Visual Fortran (which uses an oldish version of MS
> Visual studio if I'm not mistaken), and I'm using ifort (hopefully
> gfortran soon). Any idea if CVF/ MS Visual studio will dislike unix line
> endings?
In general, tla never changes your line endings for you. So if you check
in a file with DOS (CRLF) endings, you get them back that way on all
platforms.

If you are using Leroy's original release (and not my patched version),
you can run into problems with line-endings. The only real requirement
is to have a wrapper around 'patch' which supplies the '--binary' flag.
(Without it patch will change line endings)

MS Visual Studio will consider .vcproj and .sln files with UNIX endings
to be corrupted (I *think* the same is true for .dsp and .dsw, but I
don't remember). But for regular source files, it doesn't seem to care.
And newer versions even preserve line endings. I believe v6 used to
always insert CRLF, even though it read LF just fine. But v7.1
determines ending based on the endings in the file.

I don't know about CVF, and it has been a while since I used the earlier
versions of VS. (C++ compliance before 7.1 was absolutely abysmal).

If you want to try any of my releases (both short-path or pcomp/dos), I
will try to help you. It-works-for-me doesn't me it will work
everywhere, but if you are willing to help me track down any problems, I
will try to help.

> Thanks
> Neilen
John
=:->

signature.asc
Description: OpenPGP digital signature