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

[James Blackwell]

Ron Parker wrote:
> Hmm, James, I was just contemplating posting a message about a
> partially completed feature to get feed back.

Though I really appreciate your endorsement, I should probably make sure
that you're aware that I'm not the project lead. For that, you should
defer to Tom Lord. :) 

> 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.

I kind of remember the discussion we had. Wasn't it tangenital to
another conversation?


> 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

Ohhh, that's pretty.

> Then "tla import -S" yields an archive like:
>
> .../junk/junk--devo/junk--devo--1.0/base-0/log

And prettier still.

[But there's a problem. This results in shorter-path changesets being
stored in the archive, which will certainly break older clients]

> 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.

I agree. If you can stick with long patch form in the changeset
(question: would this overflow the path in windows too?), that would be
a good thing.

> As I see it there are three ways to handle this:
>
> 1) Use a patched tar, a la the =dirname pathcompression support.

Bad.

> 2) Postprocess the tar file to massage it into long-path form.

Scary.

> 3) Pipe the output from tar through a filtering process before gzip'ing it.

> 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.

I'm pretty sure that we already demand gzip. Even if we didn't, I think
this is a reasonable burden.



> [4] 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.

re 4) It could, but it would be messy. Imagine building the new changeset
in /tmp instead of in '.' That should free up enough room in the path to
solve the problem. Of course, that begs the question "but how do you
know that you're on a brain-damaged filesystem in the first place", to
which I suppose I could reply "by having a flag in .arch-params"

I'm not quite sure exactly what you have in mind for #3, but the wording
in your analysis makes it sound more appealing than #4.


> 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.

1.13.what? On my system, I've got 1.13.96, and tar seems to work 
fine in pipes.


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

I prefer, in order of preference: 3, 4, 2. 


However, there *is* an option #5. Just move everybody to shorter-path,
bump the archive version, and force people to upgrade. Normally, of
course people say "HECK NO!", but I think there may be other things
coming down the pipe that make this option palatable.


> 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?
>

Where's your changes. I'll take a look at it and see if I see anything
obviously errant. How's that sound?


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400