gnu-arch-users
[Top][All Lists]
Advanced

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

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


From: John Meinel
Subject: Re: [Gnu-arch-users] (my) tla on windows roadmap
Date: Wed, 07 Jul 2004 12:02:55 -0500
User-agent: Mozilla Thunderbird 0.7 (Windows/20040616)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Johannes Berg wrote:

| Hi,
|
| since there's been talk about windows again, I figured I'd take the time
| and write something about my thoughts.
|
| Here are a couple of suggestions/things I might do:
|  1) do not path-compress the archives, but rather force the user to
|     use shorter category names. That way we can keep archive format
|     compatibility with the linux version.
|     Postpone any format changes to get shorter paths into the next
|     archive format.
|     (cf http://wiki.gnuarch.org/moin.cgi/Archive_20Format_203_20Wishlist,
|     4th point)

If all you're talking about is the archive, I think this might work. 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.

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.

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.

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

|
|  2) put all the compatiblity into hackerlab - don't mess around inside
|     tla itself.
|

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.

|  3) there are changes to make tla use .arch-inventory instead of
|     {arch}/=tagging-method. Now, this means no-one needs to access
|     files inside {arch} any more. So, on windows, we can use something
|     like berkeley db to store {arch} in.
|     Requires: implementing a bdb vu backend.

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

|
|  4) fix at least some of the things on
|     http://wiki.gnuarch.org/moin.cgi/tla_20win32_20todo
|     that includes sections 3.1, 3.2
|
| In any case. I've mapped out what I think is a good plan to create a
| native tla for windows, but haven't gotten many comments so far.
|
| Do you all think that this is futile?
|
| johannes
|
|

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.

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.

But actually, if we get the archive format (and also the format inside
of {arch}) changed, I think we'll be a long way towards our goal.

John
=:->


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA7Cy/JdeBCYSNAAMRAtFiAKCJEuyr9ESjyrJnG3FJIcdRWtOPBQCcDyRy
Cymc/qTkBmIQLvP5xH5dEEA=
=Oc5t
-----END PGP SIGNATURE-----




reply via email to

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