Re: [Gnu-arch-users] (my) tla on windows roadmap

[Johannes Berg]

On Wed, 2004-07-07 at 19:02, John Meinel wrote:

> Well, I'll comment on this a little bit.

Thanks :)

> If all you're talking about is the archive, I think this might work. 

Yes, at this point I am.

> We
> will have to be careful about recommended usage, because you also need
> to recommend having a short start path (meaning putting the archive in
> "C:\Documents and Settings\My Username\My Documents" is also not good.)
> 
> But if we limit category names to say 30 characters, I think it will
> help a lot.

I think for now this is not really a limiting factor. Sure, future
archive formats should take this into account. Now patching up the
current archive format with path-name compression would IMHO be stupid,
since then we might as well evolve to a completely new version.

> As a side note, the paths are long, but so are the tarballs. In the
> archive the total length is:
> root/c/c--b/c--b--v/patch-nn/c--b--v--patch-nn.patches.tar.gz
> So category gets expanded 4 times, branch 3, version twice, and patch-nn
> twice.
> With a category of 30 chars, and a branch of 20, you are talking 200
> characters right there. In some ways branches are at least as important
> as categories, especially to work with people doing microbranch stuff.

Yeah, good point.

Still, I think there's another thing to consider: people working on
windows can use a linux box (ftp,sftp,dav server) to store the archive
and completely forget about this issue.

> Note that with the archive format change, you end up only using 100
> chars for the same category and branch. What if we just do that instead
> of path compression? In my personal archive, with the projects with
> extra long names, this changed the lengths from 256 -> 167, which brings
> it into the realm of just working again.

So we agree that
  a) for now we limit things and leave the archive format
  b) for future archive formats, we take the length into account
  c) it doesn't make sense patching up the current archive format
     into a version 2a archive format instead of just going to 3.

> What usually fails, though, is the "get", which creates
> ",,get.../,,pristines.../" and then the full tree.

I know. But part of that problem is the extremely long temporary
filename for ",,get..." which could be addressed differently.

> I'm not really sure of any changes that exist outside of hackerlab,
> unless you are talking about all the changes to the fork/exec logic etc.
> For any filesystem stuff, I'm pretty sure we're well contained in hackerlab.

Good :) I wasn't sure about the stuff you were doing now with lode's
patches.

> Well, I know one of rdp's requests was that you could tar up your
> working directory, send it to someone, and it could work for them.
> Otherwise I like the idea of using a db in {arch}.

So we could add the possibility of using a db for {arch} on linux as
well =)

> Actually, no I don't. I realize I'm one of the ones that should have
> commented more, but when I've tried to use your port it didn't really
> work for me. Also, I found that I had a lot of problems with the shell.
> Trying to get the PATH to work so it would use the correct programs and
> all, didn't seem to work quite right.

It should have worked if you put all the exe files into a single
directory (tla,tar,gzip,tar.real etc) because windows searches the path
where tla is stored _first_ if tla is trying to execute another program.

> One other thing to keep in mind through all of this, is that we don't
> just want a native win32 port, we also (as rdp would point out) want a
> native Mac port. Which is why the argument for =dirnames instead of the
> dos-8.3 hack.

Which again makes sense. But, otoh, how much dirname hacking do we need
to do once we have a db instead of {arch}/?
[Which reminds me: we should probably disable pristines in that db,
they'd suck too much in there, can we agree that people need a revision
library? I need to look into the pristines thing, will tla ever
"upgrade" pristines from one revision to another, or copy them?]


johannes

signature.asc
Description: This is a digitally signed message part