[Top][All Lists]

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

Re: [Gnu-arch-users] Bounty for tla on win32

From: John F Meinel Jr
Subject: Re: [Gnu-arch-users] Bounty for tla on win32
Date: Tue, 30 Mar 2004 16:41:14 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

One of the big things for path compression would be to support the alternative naming scheme. So instead of requiring category/category--branch/category--branch--version/... you could just do category/branch/version, as at least for my projects, the category is very long, and repeating it 3 times is fairly expensive. This seems like you could have a check, so that if there is a '--' in the name, then you know it is category--branch, and if it's not there, it is branch. I know it was mentioned that the code is simpler the other way, but it really eats up a lot of space.

I've never had revision libraries working under cygwin, but it isn't terrible for me. It would probably run faster if I had it, but I just need it to work, speed is secondary.

There are several places where tla uses extra long paths that are all temporary locations, and this is probably where I have the most problems. So when you first unpack a patch, I believe it untar's it into ,,get............/category/cat-branch/cat-branch-version/archive-name/, and all of these are long. In the final tree, it repeats this structure a couple of times.

Pristine trees are also a problem, as they frequently have 2 copies of the extended path:
(vida happens to be the shortest category name I have. Most of them are more like "shared-simple-image", I have one that is 42 characters long, but I don't actually use that one.)

I've also had problems with commits, where it actually succeeds in the commit, but then dies after I give my signature. The commit exists in the repository, but locally I have a ,,commit* directory left. (And this directory name is also very long just by itself.)

For path compression, the only things we want to compress are the tla managed directories. So everything under {arch}, and wherever the local archive resides. (Again, I've never had a local archive). Is it possible to be aware of where tla is looking instead of just doing a plain regular expression matching? Because somewhere it knows that it is looking for a system file, versus looking for a source file.

I will try to write up some specific examples of where I have problems with tla under cygwin.

Ron Parker wrote:

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

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

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

Thoughts? Opinions? Input?

reply via email to

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