[Gnu-arch-users] Initial short-path support

[Ron Parker]

Hmm, James, I was just contemplating posting a message about a
partially completed feature to get feed back.

As promised, I have been doing a little work on the short-path support
for tla in my "spare" time. What I have so far is basic support in
init-tree and import as well as some tests integrated into the
testsuite.

Doing a "tla init-tree --short-path junk--devo--1.0" in a directory
yields an {arch} directory with the following:

./{arch}/junk
./{arch}/junk/devo
./{arch}/junk/devo/1.0
./{arch}/junk/devo/1.0/address@hidden
./{arch}/junk/devo/1.0/address@hidden/patch-log
./{arch}/++default-version
./{arch}/.arch-project-tree
./{arch}/+short-path
./{arch}/=tagging-method

Then "tla import -S" yields an archive like:

.../junk
.../junk/junk--devo
.../junk/junk--devo/junk--devo--1.0
.../junk/junk--devo/junk--devo--1.0/base-0
.../junk/junk--devo/junk--devo--1.0/base-0/log
.../junk/junk--devo/junk--devo--1.0/base-0/++revision-lock
.../junk/junk--devo/junk--devo--1.0/base-0/++revision-lock/+contents
.../junk/junk--devo/junk--devo--1.0/base-0/checksum
.../junk/junk--devo/junk--devo--1.0/base-0/junk--devo--1.0--base-0.src.tar.gz

which is what I expect at this point since the archive is not set to
use the short-path directory names.

Here is the next issue on my plate. If you "tar tzvf
.../junk--devo--1.0--base-0.src.tar.gz" you will see:

... junk--devo--1.0--base-0
... junk--devo--1.0--base-0/{arch}
... junk--devo--1.0--base-0/{arch}/junk
... junk--devo--1.0--base-0/{arch}/junk/devo
... junk--devo--1.0--base-0/{arch}/junk/devo/1.0
... junk--devo--1.0--base-0/{arch}/junk/devo/1.0/address@hidden
... junk--devo--1.0--base-0/{arch}/junk/devo/1.0/address@hidden/patch-log
... junk--devo--1.0--base-0/{arch}/junk/devo/1.0/address@hidden/patch-log/base-0
... junk--devo--1.0--base-0/{arch}/.arch-project-tree
... junk--devo--1.0--base-0/{arch}/=tagging-method

Now obviously this has created a short-path tar file. What may not be
obvious is that the archive is a long-path archive. Unless we want to
break existing archives by creating incompatible tarballs within them,
something has to be done with respect to this.

My preference is to always have the tarballs be in long-path form.
Regardless of the short-vs-long path nature of the archive. This
allows us to use a short-path client against a long-path archive and
allows for mirroring an archive that has a different path type.

As I see it there are three ways to handle this:

1) Use a patched tar, a la the =dirname pathcompression support.
2) Postprocess the tar file to massage it into long-path form.
3) Pipe the output from tar through a filtering process before gzip'ing it.

Strictly speaking there is a fourth way, always create the pristines
in long-path form, but that will not work on short-path only systems.

Here's my take on this:

1) Requires distributing and maintaining a patched tar.  This
increases the distribution size of tla and will require some
maintenance of the patches by someone that cares.  At this point, tla
would be relying upon customized utilities.
2) Seems ugly to me. It is doable, but essentially requires having to
generate two tar files, the short-path version and the converted one.
It also requires deleting the original tar file after the conversion
is done.
3) This is basically a couple of extra pipe/fork/exec calls. It does
require making tla reliant upon gzip, but it is already implicitly so
by its use of tar's -z option.

Just to clarify this, what I have in mind is updating
make_tmp_tar_archive to have tar write to a pipe, which would in turn
be piped to a filter in a child process. This child would rewrite the
header blocks in their long form. Then its output would be piped in
turn to gzip which would ultimately write out the actual tar.gz file.

Now, as I am writing this I see the following comment in the source:
GNU tar 1.13 is busted and doesn't output to pipes correctly. Could
someone please elaborate on that as it may put an end to idea three.

If 3, is undoable, 2 would be my preference.

Now all of that being said, feel free to give me your opinions. I am
also interested in which approach is most likely to get integrated
with the mainline or is there another, better, approach I have
overlooked?