Re: [Gnu-arch-users] Premières impressions au sujet de arch (forgive me to post this in french)

[James Blackwell]

Thanks for the translation, Gonzalo

><translation>
>
> Hello,
>
> I have used arch for the first time not long a go for a small
> project. As it is still a new piece of software I would like you to
> know my impressions in an effort to make it better.
>
> - Configuration file naming:
>
>    The "{arch}" directory and the files beginning with ",,", "++"
>    and "=" are not too pretty and are not practical to use
>    (specially for shell competion). Also, this syntax poses a
>    problem with certain ftp servers, at least with proftpd and
>    pureftp.

I went through a good deal of effort to explain this at
http://wiki.gnuarch.org/moin.cgi/FunkyFileNames. I see that others have 
since updated it to be even more complete. Perhaps somebody that
knows french can translate this page for you.

> - Configuration file orgalization:
>
>    "{arch}" can be found in the root directory, and in every
>    subdirectory there are ".arch-ids". It would seem better to group
>    everything in one and only directory (".arch" for example).

The same file name can exist in different directories, for example
a/somefile and b/somefile. If there were a global .arch-ids dir, there
would be a conflict when arch tried to make two somefile.id files.

There has been talk off and on about writing arch ids into one single
file, but nobody has gone through the work to do this yet. I'm not sure
what Tom thinks about it. 


> - Amount of configuration files:
>
>    It seems to me that there is an enormous amount; I have not
>    participated in the implementation of arch, so I cannot really
>    judge all its needs at this level, but it seems to me that there
>    might be redundance in the tree layout. More clearly:
>
>       In the root of my project, in the "{arch}" directory, one can
>       find the tree structure in a directory with the same name as
>       the project; this same tree structure can also be found in a
>       directory named "++pristrine-trees".

You'll get along better if you consider the {arch} directory as an
opaque structure. The main exeption is editing the =tagging-method file.

The "++pristrine-trees" dir (actually ++pristine-trees) is there because
you have not set up libraries yet. The use of pristine-trees is a backup
method when you aren't using a revision library.

> - Use of inodes:
>
>    I have seen that in the configuration files you save the inodes
>    of the files to be saved. This poses a delicate problem:
>
>       I have a computer A with the "tla" binary and a laptop B
>       without the "tla" binary.
>        * in A I do a checkout and I make a tarball from what I
>           recover.
>        * I scp this tarball to B In B I unpack the file and work
>        * on the project I repack and scp the result to A In A I
>        * unpack and I try to commit, but it says there is a
>           problem with the inodes.
>
>    I find this very limiting and I unfortunately cannot see the
>    interest in doing so.

Yes, your inode signatures will now be considered "corrupt". You can
simply remove the old pristine trees (arch will rebuild them as 
necessary) or use revision libraries
>
> - Separation by "--":
>
>    In many parameters of the tree structure, one needs to separate
>    them by "--"; I don't find this too effective or pretty, and I
>    would find it mare useful to well separated parameters (for
>    example different arguments at the command line level).

This is a matter of preference.

> - The name of the creator in the root:
>
>    To get the sources of the project at initialisation time, or to
>    create the project for the first time, it is necessary to write
>    $ID_OF_CREATOR-.... I don't find the presence of the id a good
>    idea since during the project lifetime the ide of this person
>    will stay the same even if the person leaves the project or if he
>    hasn't been at the head of it.

Each patch has the id of the person that committed the patch. No matter
how many old developers quit, or new developers show up, the person that
commits category--branch--version--base-0 will always remain the same. 


-- 
James Blackwell          Please do not send me carbon copies of mailing
Smile more!              list posts. Such mail is unsolicited. Thank you!

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