Is anyone interested?
Well, since I was already doing some work along those lines, yes.
Originally I was working on a set of patches for Cygwin that would correct
the problem at the source, but there were two issues with this.
Microsoft's own tools, like Explorer, fall over and die on deep paths and
RedHat is requiring a release from my employer, despite not having granted
them right to the work I do. This is a problem, because my employer's
legal department was overly paranoid about the passage in the release
relating to future contributions. CGF didn't really seem to want to hook
them up with RH legal to work this out. They did agree to grant a release
with warranty period once the entire work was done, but that doesn't tend
to be the way any reasonable programmer likes to integrate changes,
instead preferring small discrete changes. So I more or less abandoned
this approach when Lode's patches became available. Not that there is no
value in adding this support to Cygwin, but many have expressed a desire
not to cause problems with the MS tools.
So, to this point my tactic has been to work toward a more general
solution using Lode's patches. My current status is that I have a build
environment for tla and the tools that support it with a partial test
suite. This test suite is not integrated with the other tests in Tom's
archive, but is a "simple" script that walks through the tutorial. I
considered that a good first cut at coverage testing tla.
I would be happy to provide bug reports and listings of my current
problems with the cygwin port. I also could help some with the
development, I just don't have a lot of time to work on it. Also, I
would like the development to be done in the open, and as compatible
with mainline tla as possible. Then depending on what changed, maybe
some of it could be merged into mainline tla.
Please go ahead and post your reports of what is broken and I will compare
them with mine. The bug I was looking at currently was a problem with
revlibs.
Well, I've been working with tla on win32 for a while now (using Leroy's
cygwin port). And while it works _most_ of the time, it doesn't work all
the way. [1] I would love to contribute time to perfecting it, but I am
already on a tight deadline for the project which _uses_ arch.
The one unfortunate thing for me is that I am on a tight schedule at work,
so this has to be done in the evenings.
So instead, I'm willing to put my money where my mouth is and offer to
give some money[2] for people to have the time to work on it.
This should help free up some time in the evenings with my wife.
[2] Since it is just me, it's not like I can hire a full-time
programmer, but I am willing to put up a few hundred dollars. Obviously,
this would be more of an iterative thing than a lump-sum payment, since
I would prefer to pay as things work, rather than pay all up front, and
I'm sure whoever helps doesn't just want to wait until it's all done to
get paid.
I am less worried about the entire amount and more concerned with some
milestones that would be considered as progress.
For the time being here is what I will try to do, when I get home this
evening:
1. Load my Cygwin related stuff onto my Mac, where I have a known working
tla, minus resource fork support. But that is a non-issue for Cygwin. I
have to do this due to bugs in the Windows tla client at this time that
seem to be introducing corruption or at least an inability to always
access what has going into archives, caches and revlibs.
2. Get the build working there.
3. Push the entire thing as an archive to commonly accessible site where
all can see and work with what is there. This will include the GNU
diffutils, patch and tar in addition to tla.
This should allow me to easily distribute changes as they progress. It
will also provide those that are interested with a starting environment
for this work. Getting lode's patches to work with tla and the GNU stuff
is quite manual at this point.
For those that have not looked at Lode's patches, they compress paths
based upon partially matching the path name. In some respects, this
further restricts tla. For example the archive path must contain
"{archive(s)}", I'm not looking at the code at the moment so I'm not sure
about the "s", but you get the point.
I think for the sake of total interoperability we need to be able to not
just pathcompress "local" archives, but to share pathcompressed archives
as well no matter where they exist. If we cannot do this, no one will be
able to use even Apache on Windows to serve an archive.
I realize this would require a change to the archive "protocol". I think
it could be done as an optional feature marked by some metadata near the
root of the archive. This would of course be best done, IMO, with Tom's
approval because we should bump the archive format version so that clients
can report it as a newer version of archive instead of a corrupted
archive.
Thoughts? Opinions? Input?