gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] TLA on Cygwin


From: Tom Lord
Subject: Re: [Gnu-arch-users] TLA on Cygwin
Date: Wed, 17 Sep 2003 16:02:46 -0700 (PDT)

    > From: "Parker, Ron" <address@hidden>

    > Given all of this, my question is, how objectionable would eliminating the
    > path name redundancy from arch be?  

What are you going to do about all those revisions that already use
the existing paths?   For example, simply untarring certain base-0
revisions will want to create paths of the current sort.

If you can handle those cleanly without too much bloat, then it's an
option.  Not a great option -- as it will impact tools like
Perspective and ViewArch but at least something that doesn't get
immediately swept off the table.  

Please note that I am _not_ encouraging you to go down this path --
just pointing out necessary but not necessarily sufficient conditions
for doing so.



    > This essentially means that the whole thing would need to be
    > implemented using only the Windows API, yuck, yuck and
    > double-yuck!

Really?  I admit, I don't much care about or know about Windows API.
However, it seems to me that there are tons of compatability layers 
to run apps that originate on unix on windows.   One that might be of
particular interest is in Tcl.

Would it really be that much work to do enough of a hackerlab port to
windows to be useful?

Failing that, there's a sort of sleazy option that may be the right
balance between "not too much work" and "solves the problem cleanly".

As you've no doubt noticed, hackerlab indirects the filesystem system
calls and programs can impose translation layers there.   Perhaps you
could make a layer that encodes the long paths in some way, more or
less transparently.    It would still be necessary to figure out how
to handle the translated paths when dealing with something like a
fork/exec of diff, tar, or patch -- but those problems might not be
too bad.

Finally, my understanding is that it is far from impossible to solve
these issues in Cygwin, but that nobody has volunteered or paid for
the labor to do so.   I would have thought that this would be a
valuable thing to do -- so I'm surprised it hasn't happened.
Whatever the reasons, it might be something to consider.


-t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]